search for: cansinkorhoistinst

...nt is marked nocapture. ; Function Attrs: nounwind readonly declare i64 @strlen(i8* nocapture) local_unnamed_addr #2 attributes #2 = { nounwind readonly ... } Presumably this should be enough to permit LICM to move it out of the loop. Upon a further investigation, the issue appeared to be that canSinkOrHoistInst didn't figure out that the call could be moved. Curious as to see what I might be able to do to be able to do to force it to happen, I declared my own version of the strlen as follows (which, though technically incorrect as it read memory, did confirm that LICM isn't being stopped for som...

...isSafeToSpeculativelyExecute() always returns false for Call >> instructions. >> This has actual performance implications, because loop-invariant code motion >> makes this check, and will never hoist instructions that are not safe to >> speculatively execute. > > LICM::canSinkOrHoistInst has special handling for hoisting Call Instructiobns. > It looks like readonly functions should be hoisted. Do you have test cases > which fail ? a readonly/readnone function may contain divide by zero. Ciao, Duncan.

...gt; Hello, > > Currently, llvm::isSafeToSpeculativelyExecute() always returns false for Call instructions. > This has actual performance implications, because loop-invariant code motion makes this check, and will never hoist instructions that are not safe to speculatively execute. LICM::canSinkOrHoistInst has special handling for hoisting Call Instructiobns. It looks like readonly functions should be hoisted. Do you have test cases which fail ? Thanks, Nadav -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/2012...

Hello, Currently, llvm::isSafeToSpeculativelyExecute() always returns false for Call instructions. This has actual performance implications, because loop-invariant code motion makes this check, and will never hoist instructions that are not safe to speculatively execute. Unfortunately, there is currently no way to signal to LICM that a function is safe to speculatively execute. The

...*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/7f0da2b3/attachment.html>

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. (Adding unit tests for reverse it...

...lso 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 fine if they are loop invariant and...