Menu
▾
▴
Re: [avr-llvm-devel] Inline assembly. Mostly just a stub.
|
From: Borja F. <bor...@gm...> - 2013-06-29 13:51:19
|
Stepan I've been testing the memory constraint but im getting an assertion
for the following code:
uint8_t delay(unsigned char **p)
{
uint8_t cnt=8;
asm volatile (
"ld %0, %1" "\n\t"
: "=r" (cnt)
: "Q" (p[7]));
return cnt;
}
What's wrong in here?
2013/6/29 Borja Ferrer <bor...@gm...>
> 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>
>>>>
>>>>
>>>
>>
>
|
