Menu
▾
▴
Re: [avr-llvm-devel] Inline assembly. Mostly just a stub.
|
From: Borja F. <bor...@gm...> - 2013-06-28 20:11:48
|
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>
>>
>>
>
|
