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> >>> >>> >> > |