search for: ismoveinstr

I've tried to implement the isMoveInstr method from TargetInstrInfo class, and the register allocator immediately started to crash, in: #4 0x40e88787 in llvm::LiveIntervals::joinIntervals (this=0x80630b0) at ../lib/CodeGen/LiveIntervals.cpp:493 493 assert(r2iA != r2iMap_.end()); The instruction it crashes is:...

On Thu, 2004-07-01 at 09:26, Vladimir Prus wrote: > I've tried to implement the isMoveInstr method from TargetInstrInfo class, and > the register allocator immediately started to crash, in: > > #4 0x40e88787 in llvm::LiveIntervals::joinIntervals (this=0x80630b0) > at ../lib/CodeGen/LiveIntervals.cpp:493 > 493 assert(r2iA != r2iMap_.end()); > &...

...uot;goto">; def IFEQ : Unknown<"if =0 goto">; def IFNEQ : Unknown<"if <>0 goto">; ..... Should this work? > Also, if you haven't already, you might want to teach TargetInstrInfo > that '=' is a move instruction (implement isMoveInstr), so instructinos > like 'gr1 = gr1' will go away and you'll get coallescing. :) BTW, is it possible to set some instruction flag, instead of overriding a function? Something like: let isMove = 1 in def MOVE :..... ? - Volodya

...; ..... } ... aka add {} Also, if you do 'tblgen target.td' it will spit out all of the records to stdout so you can visually inspect them. > > Also, if you haven't already, you might want to teach TargetInstrInfo > > that '=' is a move instruction (implement isMoveInstr), so instructinos > > like 'gr1 = gr1' will go away and you'll get coallescing. :) > > BTW, is it possible to set some instruction flag, instead of overriding a > function? Something like: > > let isMove = 1 in > def MOVE :..... That would make sense, but...

..._2<kill> It will also replace the TargetInstrInfo::copyRegToReg hook when copying virtual registers: %reg1050 = COPY %reg1044<kill> It will be lowered with a TII.copyRegToReg() call in LowerSubregsInstructionPass (which may need renaming). Why? 1. The new function CoalescerPair::isMoveInstr() can correctly determine if a MachineInstr is a (partial) register copy with source and destination registers and subreg indices. I think that is the only place it is done correctly currently. Weird stuff like subreg indices on EXTRACT_SUBREG operands is pretty hard to figure out. The COPY instruc...

...ldr r14, [r13, #0] add r13, r13, #4 bx r14 ------------------------------------------ It would be better to do a "mov r0, #42" directly. The isel dag is almost identical to the one generated for ppc32, but on ppc32 "li r3, 42" is used. I have checked that isMoveInstr returns true for the "mov r0,r 4". Does someone has any idea why the additional mov is generated? Thanks, Rafael

Maybe it's because I've got a lot of two machine operand instructions and have to rely on the tied-to constraint, but I'm seeing a lot of dead reg-to-reg copy instructions, e.g.: ori $3, $3, 0 (Cell SPU's version of reg-to-reg copy, looks a lot like PPC, no?) Is there any way I can detect when this occurs, or is there code where this detection takes place in the target to which

On 1/18/07, Scott Michel <scottm at rushg.aero.org> wrote: > Is there any way I can detect when this occurs, or is there code > where this detection takes place in the target to which I can > refer? have you implemented InstInfo::isMoveInstr to recognize those? The register allocator uses that to find copies it can remove. Andrew

...[SDNPCommutative, SDNPAssociative]>; ... and assumed it was sufficient, since I saw no other targets making special arrangements. I see no obvious (to me, anyway 8^) "copy instruction" property. The insn in question is generated by copyRegToReg(), and satisfies the isMoveInstr() predicate. G

...or flag on your 'if <>0 goto LBB11;' things will probably magically start working for you, as the copies will be inserted BEFORE the branch instead of after it. Also, if you haven't already, you might want to teach TargetInstrInfo that '=' is a move instruction (implement isMoveInstr), so instructinos like 'gr1 = gr1' will go away and you'll get coallescing. :) -Chris > I also attach the debug dumps from my backend. > > The basic block in question is shortcirc_done.1 (line 198 in the log). It > starts with: > > %reg1060 = phi %reg1032, mbb&l...

...For example, it's hard for me to read %reg1045:sub_32bit<def> = COPY %reg1044<kill> as updating part of reg1045. It's solvable by pretty printing COPY instructions that include register class information. > > > Why? > > > 1. The new function CoalescerPair::isMoveInstr() can correctly determine if a MachineInstr is a (partial) register copy with source and destination registers and subreg indices. I think that is the only place it is done correctly currently. Weird stuff like subreg indices on EXTRACT_SUBREG operands is pretty hard to figure out. The COPY instruc...

...scribed approach is a pretty inefficient code > resulting after the register allocation. For example, there are a lot > of instructions of the form "mov %d0, %d0", copying the register into > itself. My guess is that the following happens: Make sure to implement TargetInstrInfo::isMoveInstr. This will allow the coallescer to eliminate these. > before reg.alloc there are instructions of the form: > mov %virtual_reg0, %d0 > mov %virtual_reg1, %d1 > fsub64 > which ensure that operand constraints of the operation are fullfilled > and they are on the right registers. D...

Hi, I'm now ready to implement the FP support for my embedded target. My target supports only f64 at the moment. Question: How can I tell LLVM that float is the same as double on my target? May be by assigning the same register class to both MVT::f32 and MVT::f64? But FP is supported only in the emulated mode, because the target does not have any hardware support for FP. Therefore each FP

On Apr 16, 2009, at 3:17 PM, Greg McGary wrote: > I have my new port limping enough to compile a very basic function: > > int > foo (int a, int b, int c, int d) > { > return a + b - c + d; > } > > clang-cc -O2 yields: > > define i32 @foo(i32 %a, i32 %b, i32 %c, i32 %d) nounwind readnone { > entry: > %add = add i32 %b, %a ; <i32> [#uses=1]

...aw no other targets making > special arrangements. In X86InstrInfo.td, ADD32rr (and lots others) are marked isCommutable. Evan > > I see no obvious (to me, anyway 8^) "copy instruction" property. The > insn in question is generated by copyRegToReg(), and satisfies the > isMoveInstr() predicate. > > G > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Fri, 2010-06-04 at 20:05 +0200, Jakob Stoklund Olesen wrote: > You should fix SPUTargetLowering::LowerCall to make sure there is an unbroken chain of flag ties between CopyFromReg and BRASL. At least ARM, MBlaze, and Blackfin are doing this, if you need example code. > Thanks for the tip. This got fixed in 105601. And with that, half of the problematic tests appearing with

I have my new port limping enough to compile a very basic function: int foo (int a, int b, int c, int d) { return a + b - c + d; } clang-cc -O2 yields: define i32 @foo(i32 %a, i32 %b, i32 %c, i32 %d) nounwind readnone { entry: %add = add i32 %b, %a ; <i32> [#uses=1] %sub = sub i32 %add, %c ; <i32> [#uses=1] %add4 = add i32 %sub, %d ; <i32>

On Jan 9, 2007, at 10:01 AM, Scott Michel wrote: > I was able to resolve my previous question about dealing with custom > loads/stores, and following Chris' suggestion, the IBM Cell SPU > backend > can generate code for "int main(void) { return 0; }" without crashing > llc. There's a lot of work still to be done... like getting frame > offsets correctly

On Jun 4, 2010, at 1:57 AM, <Kalle.Raiskila at nokia.com> <Kalle.Raiskila at nokia.com> wrote: > On Thu, 2010-06-03 at 02:53 +0200, Jakob Stoklund Olesen wrote: >> If you are using the local register allocator, please try switching to the fast allocator and report any bugs you find. >> > Tried it, and it seems to break quite a big chunk of our tests on SPU :)

I was able to resolve my previous question about dealing with custom loads/stores, and following Chris' suggestion, the IBM Cell SPU backend can generate code for "int main(void) { return 0; }" without crashing llc. There's a lot of work still to be done... like getting frame offsets correctly computed and hauling in the raft of intrinsics that the Cell SDK defines. Three quick