From: Stepan D. <stp...@na...> - 2013-06-27 17:21:21
|
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...>> > > No, your last email only says : "So, can I commit that memory > constraint patch?" > > > 2013/6/27 Stepan Dyatkovskiy <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...>> > To: Borja Ferrer <bor...@gm... > <mailto:bor...@gm...>> > CC: avr-llvm <avr-llvm-devel@lists.__sourceforge.net > <mailto:avr...@li...>>, John Myers > <ato...@gm... <mailto: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...>>> > > 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. > > > > > > > > |