From: Borja F. <bor...@gm...> - 2013-06-27 17:55:37
|
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...> > 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... >> >> >> >> >> 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...>** >> >__> >> >> >> 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...>>> >> >> >> >> 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...>>> >> To: Borja Ferrer <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://sourceforge.net> >> <mailto:avr-llvm-devel@lists._**_sourceforge.net >> >> <mailto:avr-llvm-devel@lists.**sourceforge.net<avr...@li...>>>>, >> John Myers >> <ato...@gm... >> <mailto:atomicdog.jwm@gmail.**com <ato...@gm...>> >> <mailto:atomicdog.jwm@gmail.__**com <mailto:atomicdog.jwm@gmail.* >> *com <ato...@gm...>>>> >> >> >> Hi Borja, >> >> 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 >> >> >> >> >> 2013/6/25 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... >> >>>> >> >> >> Hi Borja. >> This is new patch. Seems I've moved memory >> constraint >> implementation >> to the same level like all other constraints. >> Note >> avr-gcc has buggy >> implementation of memory constraint, that's why >> *avr-libc doesn't >> use it*. >> >> I removed restriction for Y,Z in >> getLargestLegalSuperClass, so these >> registers could be inflated now. But there was >> unimplemented >> getPointerRegClass method in AVRRegistersInfo. >> So >> currently I have >> restricted it to Y and Z. Though suppose we >> can extend >> it in future >> to XYZ set. >> Look changes in inline-asm.ll to see what >> exactly is >> supported now. >> >> About clang. >> May be we ask John Myers to fix clang support >> for >> inline asm? >> >> -Stepan. >> >> >> Stepan Dyatkovskiy wrote: >> >> The patch. Forgot to attach it. >> -Stepan. >> Stepan Dyatkovskiy wrote: >> >> Hi Borja, >> >> > What happens in your example above >> when you >> use a real >> instruction >> like >> >> for example LDD? Does it still use >> GPR8 >> regs? To me it's >> weird that if >> you use a real instruction where >> operands >> are clearly >> defined in the td >> file the instruction selector uses >> an >> invalid regclass. >> >> >> There are two kinds of inline asm >> support in LLVM: >> 1. You just support all the >> constraints and pastes >> inline-asm contents >> as-is. That's why its still allowed to >> use >> names like >> "some_instr". >> 2. You may expand inline-asm strings >> set, or in >> another >> words just parse >> it onto set of instructions. In this >> case you >> have to implement >> TargetLowering::______**ExpandInlineAsm >> >> method. >> >> I'd want to start it on this week >> though... >> >> But first we have to get avr-libc >> compilable >> (perhpas I read you >> thoughts ;-) ) >> >> Relative to memory constrains. I >> implemented >> initial version >> it can >> catch simplest cases (from test-case): >> >> @a = internal global i16 0, align 4 >> @b = internal global i16 0, align 4 >> define void @mem() { >> ;CHECK: some_instr Z, Y >> call void asm "some_instr $0, $1", >> "=*Q,=*Q"(i16* @a, >> i16* @b) >> ret void >> } >> >> The patch is attached. >> >> Its in my todo yet, to handle local >> variables. >> They could be >> emitted as >> Y+q expression. Hope to present this >> support >> tomorrow. So if >> 'a' and 'b' >> from example above would be local we >> could get >> "some_instr >> Y, Y+2" >> >> -Stepan. >> >> >> >> >> >> >> >> >> >> >> > |