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