Re: [avr-llvm-devel] Inline assembly. Mostly just a stub.

[Stepan D. <stp...@na...>]

Hi Borja,
1. Yes, avr-gcc, supports i64.
2. Well I'd want to *keep* an assertion. IMHO ee should legalize operands that are bigger than i16 by expanding onto set of either i8 or i16 registers in future.
-Stepan

> 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  > >> 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 >> >>> > >>> >>> 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 >> >>> > >>> >>> 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 >> >>>  >> >>> >> >>> >>> 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 >> >>>  >>> >>> >> >>> > >>> >>> >> >>>  >>> >>> >> >>> >__>__> >>> >>> No, your last email only says : "So, >>> >>> can I >>> >>> commit that memory >>> >>> constraint patch?" >>> >>> 2013/6/27 Stepan Dyatkovskiy >>> >>>  >>> >>> >> >>> > >>> >>> >> >>>  >> >>> >>> >>> >>> 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 >>> >>>  >>> >>> >> >>> > >>> >>> >> >>>  >> >>> >>> >>> >>> To: Borja Ferrer >>> >>> >> >>>  >>> >>> >> >>> > >>> >>> >> >>>  >>> >>> >> >>> >__>__> >>> >>> CC: avr-llvm >>> >>> >> >>>  >>> >>>  >>> >>>  -- Truly yours, Stepan Dyatkovskiy