Menu
▾
▴
Re: [avr-llvm-devel] Inline assembly. Mostly just a stub.
|
From: Borja F. <bor...@gm...> - 2013-06-29 12:57:05
|
1) Ok then, I will look into it.
2) Yes, in theory types should be legalized up to i16 max, but for some
reason i got that assertion triggered, i think it was with multibyte inline
asm, so this has to be solved.
2013/6/28 Borja Ferrer <bor...@gm...>
> Hello Stepan, I will take a look to your patch later, but some questions:
>
> 1) does avr-gcc support 64bit values?
> 2) now that you're working with big data types, does it make sense to
> remove the assert I commented out about value types that are different to
> i8 AND i16?
>
>
>
> 2013/6/28 Stepan Dyatkovskiy <stp...@na...>
>
>> Hi Borja.
>> This is almost the final multibyte constraint patch. Tests are not
>> created yet.
>>
>> Currently I have issue with 64 bit values. Even if I pass them as inline
>> asm operands, llvm still truncates them to i32.
>>
>> What works:
>>
>> long a; // 32 bit
>> void f() {
>> asm("instr %A0 %B0 %C0 %D0": : "r"(a));
>> }
>>
>>
>> What doesn't work:
>>
>> long long a; // 64 bit
>> void f() {
>> asm("instr %A0 %B0 %E0": : "r"(a));
>> }
>>
>> The last one fires assertion since llvm allocates registers for the first
>> 32 bits only.
>>
>> -Stepan.
>>
>> Borja Ferrer wrote:
>>
>>> Yes fine
>>>
>>> El jueves, 27 de junio de 2013, Stepan Dyatkovskiy escribió:
>>>
>>> OK. Will do.
>>> Currently there is a patch with memory constraint and draft
>>> multibyte constraint (supports only A and B). To be clean under
>>> multibyte constraints I mean something like this:
>>> asm volatile("mov __tmp_reg__, %A0" "\n\t"
>>> "mov %A0, %B0" "\n\t"
>>> "mov %B0, __tmp_reg__" "\n\t"
>>> : "=r" (value)
>>> : "0" (value)
>>> );
>>>
>>> -Stepan.
>>> Borja Ferrer wrote:
>>>
>>> btw, if this is now feature complete you can commit it.
>>>
>>>
>>> 2013/6/27 Borja Ferrer <bor...@gm...
>>> <mailto:bor...@gm...>**>
>>>
>>> No, that code is a personal modification of your examples.
>>> If you
>>> aren't getting the correct output from clang that's because
>>> you
>>> probably didn't apply a patch i commited last week for
>>> clang in our SVN.
>>> The assertion you're getting looks reasonable, it's an old
>>> friend of
>>> mine. The reason is that if Y is being reserved as the frame
>>> pointer, you cant have an instruction that uses 2 registers
>>> when
>>> only Z is available. I wouldn't mind too much about it.
>>>
>>> Now, my 2nd question:
>>>
>>> Is there anything else that needs to be covered for the
>>> memory
>>> constraint?
>>>
>>>
>>> 2013/6/27 Stepan Dyatkovskiy <stp...@na...
>>> <mailto:stp...@na...>>
>>>
>>> This one looks good. Though ./llc emits "run out of
>>> registers
>>> allocation. I'll look at it. Is that from avr-libc?
>>> -Stepan.
>>> Borja Ferrer wrote:
>>>
>>> Yes, and then I replied the following:
>>>
>>> For this C code:
>>>
>>> char delay_count;
>>> char aaa;
>>> uint8_t delay(unsigned char p)
>>> {
>>> uint8_t cnt;
>>> asm volatile (
>>> "inst %0, %1" "\n\t"
>>> : "=Q" (delay_count)
>>> : "Q" (aaa));
>>> return cnt;
>>> }
>>>
>>> Clang produces:
>>>
>>> define i8 @delay(i8 %p) #0 {
>>> entry:
>>> tail call void asm sideeffect "inst $0,
>>> $1\0A\09",
>>> "=*Q,*Q"(i8*
>>> @delay_count, i8* @aaa) #2, !srcloc !4
>>> ret i8 undef
>>> }
>>>
>>> notice the *Q constraints, so is there anything
>>> wrong in there?
>>>
>>> Is there anything else that needs to be covered for
>>> the
>>> memory constraint?
>>>
>>>
>>> 2013/6/27 Stepan Dyatkovskiy <stp...@na...
>>> <mailto:stp...@na...> <mailto:
>>> stp...@na...
>>> <mailto:stp...@na...>>>
>>>
>>>
>>> Hi Borja,
>>>
>>> > Stepan, reply in this thread to my 2
>>> questions again
>>> if the email
>>> got lost.
>>>
>>> My prev. reply:
>>>
>>>
>>> > Ahh, I didn't know avr-gcc was buggy on this
>>> feature, that's probably
>>> > the reason for why the code i pasted in my
>>> previous
>>> email didn't
>>> work.
>>> ...
>>> > What's wrong with clang? I fixed clang
>>> inline asm
>>> support back on
>>> > friday, so is there anything else that is
>>> broken?
>>> It should emit '*Q' instead of 'Q'. That's why
>>> code
>>> from prev. email
>>> didn't work, just compare -emit-llvm -S output
>>> of
>>> avr-clang with
>>> other backends,
>>>
>>> > About the getPointerRegClass function, what
>>> is it
>>> used for? Also,
>>> please
>>> > move the implementation to the cpp file
>>> instead of
>>> leaving it in
>>> the .h.
>>> Currently, it is used in registers coelescing
>>> pass.
>>> While being
>>> registers inflating, llvm lookups all register
>>> uses. If
>>> it found
>>> that register is used by inline-asm as memory
>>> operand,
>>> it requests
>>> the pointer class with this method (I think
>>> the largest
>>> one). But
>>> may be in future this method will be used in
>>> more cases.
>>>
>>> avr-gcc has buggy implementation of memory
>>> constraint,
>>> that's why
>>> avr-libs doesn't use it at all. We have a
>>> chance to be
>>> first here
>>>
>>> -Stepan
>>>
>>> Borja Ferrer wrote:
>>>
>>> Stepan, reply in this thread to my 2
>>> questions
>>> again if the
>>> email got lost.
>>>
>>>
>>> 2013/6/27 Borja Ferrer <
>>> bor...@gm...
>>> <mailto:bor...@gm...>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>**>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>**>__>__>
>>>
>>>
>>> No, your last email only says : "So,
>>> can I
>>> commit that memory
>>> constraint patch?"
>>>
>>>
>>> 2013/6/27 Stepan Dyatkovskiy
>>> <stp...@na... <mailto:stp...@na...>
>>> <mailto:stp...@na...
>>> <mailto:stp...@na...>>
>>> <mailto:stp...@na...
>>> <mailto:stp...@na...> <mailto:
>>> stp...@na...
>>> <mailto:stp...@na...>>>>
>>>
>>>
>>>
>>> Hm... Didn't you get my previous
>>> mail? If
>>> not, I think,
>>> I have
>>> to change my mail box.
>>>
>>> -Stepan
>>>
>>>
>>> -------- Original Message --------
>>> Subject: Re: [avr-llvm-devel]
>>> Inline
>>> assembly. Mostly
>>> just a stub.
>>> Date: Tue, 25 Jun 2013 18:30:46
>>> +0400
>>> From: Stepan Dyatkovskiy
>>> <stp...@na... <mailto:stp...@na...>
>>> <mailto:stp...@na...
>>> <mailto:stp...@na...>>
>>> <mailto:stp...@na...
>>> <mailto:stp...@na...> <mailto:
>>> stp...@na...
>>> <mailto:stp...@na...>>>>
>>> To: Borja Ferrer
>>> <bor...@gm...
>>> <mailto:bor...@gm...>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>**>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>**>__>__>
>>> CC: avr-llvm
>>> <avr-llvm-devel@lists.__source**______forge.net<http://source______forge.net>
>>> <http://source____forge.net>
>>> <http://source__forge.net>
>>> <http://source <http://sourceforge.net>
>>>
>>>
>>
>
|
