From: Stepan D. <stp...@na...> - 2013-06-27 08:09:47
|
Hi Borja, So, can I commit that memory constraint patch? -Stepan. Stepan Dyatkovskiy wrote: > 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...>> >> >> 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. >> >> >> >> >> > |