search for: isloopinvariantinst

my changed code. namespace { class MyLoopPass:public LoopPass { bool changed; public: static char ID; Loop* curLoop; // AnalysisType* AA; DominatorTree* DT; LoopInfo* LI; MyLoopPass() : LoopPass(ID){} bool isLoopInvariantInst(Instruction &I) ; bool runOnLoop(Loop * L, LPPassManager &lpm); virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.setPreservesCFG(); AU.addRequired<DominatorTree>(); AU.addRequired<LoopInfo>(); AU.addRequiredID(LoopSimplifyID); AU.addPreserved<ScalarE...

i am getting seg fault on functions like I->eraseFromParent also. I'm assuming that the problem comes when i change the loop structure. On Thu, Nov 18, 2010 at 4:05 AM, Sreeraj a <writetosrj at gmail.com> wrote: > The funny thing is that i am manually able to hoist the Loop invariant > instruction to the basicBlock terminator, by editing the human readable form > and then

The funny thing is that i am manually able to hoist the Loop invariant instruction to the basicBlock terminator, by editing the human readable form and then using llvm-as to convert it into bytecode. On Thu, Nov 18, 2010 at 4:01 AM, Chris Lattner <clattner at apple.com> wrote: > > On Nov 17, 2010, at 1:38 PM, Sreeraj a wrote: > > > Thanks Chris, > > > > I was

...in Mips are considered cheap (1-cycle def-use latency) by MachineLICM::IsCheapInstruction(), but are not trivially materializable because their register operands are not always available. This makes MachineLICM::IsProfitableToHoist() return false, preventing the hoist even though MachineLICM::IsLoopInvariantInst() returns true. The comment in IsProfitableToHoist() is: // If the instruction is cheap, only hoist if it is re-materilizable [sic]. LICM // will increase register pressure. It's probably not worth it if the // instruction is cheap. The function then proceeds to actually *estimate* register...

Yes machine-licm can and should hoist constant materialization instructions out of the loop. If it's not doing that, it's probably because the target is not modeling the instruction correctly. I would walk through MachineLICM::IsLoopInvariantInst() in the debugger to figure it out. You can also try compiling the same bitcode for a target like ARM or X86 as a comparison. Evan On Mar 7, 2012, at 10:38 AM, Matt Johnson wrote: > Hi All, > I work on a backend for a target similar to Mips, where large > immediates are loaded into...

Hi All, I work on a backend for a target similar to Mips, where large immediates are loaded into registers with 2 instructions, 1 to load the MSBits and 1 to load the LSBits. I've noticed a recurring pattern where, despite low register pressure, these constants will be rematerialized in every iteration of a loop, rather than being hoisted. Here's an example using the

...*LICM::HOistRegion(DomTreeNode *N)* { assert(N != 0 && "Null dominator tree node?"); BasicBlock *BB = N->getBlock(); ... * for (BasicBlock::iterator II = BB->end(); II != BB->begin(); ) *{ Instruction &I = *--II; if (isLoopInvariantInst(I) && canSinkOrHoistInst(I) && isSafeToExecuteUnconditionally(I)) * hoist(I);* } .. } -- UGR -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100111...

Hi Gang-Ryung! Your reverse iteration of instructions in the BB > * for (BasicBlock::iterator II = BB->end(); II != BB->begin(); ) *{ > > Instruction &I = *--II; > > if (isLoopInvariantInst(I) && canSinkOrHoistInst(I) && > isSafeToExecuteUnconditionally(I)) > * hoist(I);* > } looks perfectly valid. If I remember correctly, the (operator--) on Instruction has a buggy assert, but that should not trigger in your case....

...ect?) With the second approach, if I dump the IR for the module after changing the basic blocks, everything looks correct. But when the recompileAndRelinkFunction(Fn) is executed, I get the error: /home/varun/llvm-git/lib/CodeGen/MachineLICM.cpp:956: bool <anonymous namespace>::MachineLICM::IsLoopInvariantInst(llvm::MachineInstr &): Assertion `MRI->getVRegDef(Reg) && "Machine instr not mapped for this vreg?!"' failed. What am I missing? Thanks, Varun Agrawal

...invariant, and canSinkOrHoist() also returns true; however the difference is at Instruction::isSafeToSpeculativelyExecute(), for load from function parameter pointer, it return false; with load from a global var pointer, it returns true. As a result no hoist happens for a load *fp: **LICM.cpp if (isLoopInvariantInst(I) && canSinkOrHoistInst(I) && isSafeToExecuteUnconditionally(I)) // invokes I->IsSafeToSpeculativelyExecute() hoist(I); But I do not know why we need to treat fp/local pointer different with global pointer here. I think hoisting fp/local pointers should be fin...