search for: deadmachineinstructionelim

...could use another set of eyes on the issue if someone has time. This command gives me an error: valgrind -q ./bin/llc < /home/regehr/llvm/test/CodeGen/Hexagon/hwloop-dbg.ll -march=hexagon -mcpu=hexagonv4 The error is at this line: https://github.com/llvm-mirror/llvm/blob/master/lib/CodeGen/DeadMachineInstructionElim.cpp#L142 Here I've refactored the code into a minimal (noinline) function that still triggers the problem. xfunc2() and xfunc3() are also noinline. The problem goes away if either isReg() or isDef() is marked noinline. void xfuncx(const MachineOperand &MO, const TargetRegisterInfo...

Ping. Anyone have any idea on how to fix this? Thanks, Micah From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Villmow, Micah Sent: Wednesday, April 14, 2010 2:28 PM To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Default behavior of DeadMachineInstructionElim deletes all instructions Dale, Yeah that is correct, so that isn't the problem, not sure why I was thinking it is. The !MRI->use_no_dbg_empty(Reg) seems to be correct and the problem is LivePhysRegs[Reg] always returning false. I've looked into this more and there is a part where I...

On Apr 29, 2010, at 2:06 PM, Villmow, Micah wrote: > Ping. Anyone have any idea on how to fix this? Does your getAllocatableSet() return a BitVector that is at least getNumRegs() bits long? Otherwise this doesn't work: BitVector NonAllocatableRegs = TRI->getAllocatableSet(MF); NonAllocatableRegs.flip();

...BitVector Allocatable(getNumRegs()); Allocatable.clear(); return Allocatable; } Micah -----Original Message----- From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] Sent: Monday, May 03, 2010 9:52 AM To: Villmow, Micah Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Default behavior of DeadMachineInstructionElim deletes all instructions On Apr 29, 2010, at 2:06 PM, Villmow, Micah wrote: > Ping. Anyone have any idea on how to fix this? Does your getAllocatableSet() return a BitVector that is at least getNumRegs() bits long? Otherwise this doesn't work: BitVector NonAllocatableRegs = TRI->ge...

...is causing this behavior or if determining if the default assumptions by this pass are correct. Micah From: Dale Johannesen [mailto:dalej at apple.com] Sent: Wednesday, April 14, 2010 2:15 PM To: Villmow, Micah Cc: Dale Johannesen; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Default behavior of DeadMachineInstructionElim deletes all instructions On Apr 14, 2010, at 1:55 PMPDT, Villmow, Micah wrote: I've recently sync'd to a newer version of LLVM(Apple branch 2326 from Apple branch 2323.8) that changed the interface to addCommonCodeGenPasses which caused the default implementation to be executed instead...

...illmow, Micah wrote: > I’ve recently sync’d to a newer version of LLVM(Apple branch 2326 from Apple branch 2323.8) that changed the interface to addCommonCodeGenPasses which caused the default implementation to be executed instead of my overriding implementation. This default implementation has DeadMachineInstructionElim pass enabled, which is causing havoc with my backend. Before entering this pass, everything in my machine function is fine, after this pass, all instructions that are not function calls are deleted. I’ve tracked this issue down to the line: > > BitVector NonAllocatableRegs = TRI->getAlloc...

I've recently sync'd to a newer version of LLVM(Apple branch 2326 from Apple branch 2323.8) that changed the interface to addCommonCodeGenPasses which caused the default implementation to be executed instead of my overriding implementation. This default implementation has DeadMachineInstructionElim pass enabled, which is causing havoc with my backend. Before entering this pass, everything in my machine function is fine, after this pass, all instructions that are not function calls are deleted. I've tracked this issue down to the line: BitVector NonAllocatableRegs = TRI->getAllocatableS...

...is command gives me an error: >> >> valgrind -q ./bin/llc < >> /home/regehr/llvm/test/CodeGen/Hexagon/hwloop-dbg.ll -march=hexagon >> -mcpu=hexagonv4 >> >> The error is at this line: >> >> https://github.com/llvm-mirror/llvm/blob/master/lib/CodeGen/DeadMachineInstructionElim.cpp#L142 >> >> >> >> Here I've refactored the code into a minimal (noinline) function that >> still triggers the problem. xfunc2() and xfunc3() are also noinline. >> The problem goes away if either isReg() or isDef() is marked noinline. >> >> voi...

...disable various code generator optimizations. > > That said, I, like Duncan, wasn't aware that llc did any dead-code elimination (beyond peephole optimization). Are you sure llc is removing the instructions you care about? > Perhaps the dead machine instruction elimination pass? (DeadMachineInstructionElim.cpp) I don't think there's a way to disable that. -Jim

...lectcc pairs that are linked together by Flag values. The instruction selection pass converts the MSP430selectcc node to a MSP430::Select16 pseudo-instruction which is later expanded to a condition branch by a custom inserter. I'm still trying to figure out exactly why, but for some inputs the DeadMachineInstructionElim pass eliminates the compare instruction. What appears to be happening is that one of the register-to-register move instructions of the block occurs between the compare and conditional branch when the pass iterates over the instructions in reverse order. Since the architecture's move instruction...

...ions. > > > > That said, I, like Duncan, wasn't aware that llc did any dead-code > elimination (beyond peephole optimization). Are you sure llc is removing > the instructions you care about? > > > > > Perhaps the dead machine instruction elimination pass? > (DeadMachineInstructionElim.cpp) I don't think there's a way to disable > that. > > -Jim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101207/5a9cc970/attachment.html>

...:$offset)]>; I want to place the setcc result in a condition reg and then do the conditional branch with the result from the condition reg. Unfortunately, this doesn't work. The Instruction Selection itself does work, but in a later pass the compare and branch instructions are deleted: > DeadMachineInstructionElim: DELETING: BRrel <BB#3> > DeadMachineInstructionElim: DELETING: BRrel <BB#1> > DeadMachineInstructionElim: DELETING: BRcondrel %vreg1<kill>, <BB#2>; CondRegs:%vreg1 > DeadMachineInstructionElim: DELETING: %vreg1<def> = CMPri %vreg0, 0; CondRegs:%vreg1 GPRegs:%...

I have a pass that modifies my machine dependent instructions and I have ran into a situation where I want to remove all instructions that an instruction is dependent on when I remove an instruction. Is there a way to do this using the API calls? For example, I have a sequence of instructions a = b + c d = c * c store d, *a load e, *a f = e + d since the store and load are

Hi, How would I disable dead code elimination in llc? Can that be done via the command line or do I need to modify llc's source? Thanks Andrew Lukefahr andrewlukefahr at gmail.com Open Source, Open Minds -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101206/cf656247/attachment.html>

On 12/6/10 11:39 AM, Andrew Lukefahr wrote: > Hi, > > How would I disable dead code elimination in llc? Can that be done > via the command line or do I need to modify llc's source? You can use llc --help-hidden to see a list of options. There are several -disable-xxx options that disable various code generator optimizations. That said, I, like Duncan, wasn't aware that

Hi, I have the following problem: In BB0 there is an instruction that defines a flag (implicit def) and in BB1 there is one that reads the flag (implicit use). When i run llc with -O3, the instruction in BB0 that defines the flag is removed. How can i prevent this? BB0 and BB1 are consecutive basic blocks. Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed...

...ase+Asserts build llvm[2]: Compiling DFAPacketizer.cpp for Release+Asserts build llvm[3]: Compiling ConstantMerge.cpp for Release+Asserts build llvm[3]: Compiling StructurizeCFG.cpp for Release+Asserts build llvm[3]: Compiling DeadArgumentElimination.cpp for Release+Asserts build llvm[2]: Compiling DeadMachineInstructionElim.cpp for Release+Asserts build llvm[2]: Compiling DwarfEHPrepare.cpp for Release+Asserts build llvm[3]: Compiling RuntimeDyldMachO.cpp for Release+Asserts build llvm[3]: Compiling TailRecursionElimination.cpp for Release+Asserts build llvm[3]: Compiling ElimAvailExtern.cpp for Release+Asserts build...