search for: hasloopinvariantoperands

...nt the instruction from >      // executing in each iteration of the loop.  This means it is safe > to hoist >      // something that might trap, but isn't safe to hoist something > that reads >      // memory (without proving that the loop doesn't write). >      if (L->hasLoopInvariantOperands(Inst) && >          !Inst->mayReadFromMemory() && !Inst->mayWriteToMemory() && >          !isa<TerminatorInst>(Inst) && !isa<DbgInfoIntrinsic>(Inst)) { >        Inst->moveBefore(LoopEntryBranch); >        continue; >      } > &g...

...preheader, but does prevent the instruction from // executing in each iteration of the loop. This means it is safe to hoist // something that might trap, but isn't safe to hoist something that reads // memory (without proving that the loop doesn't write). if (L->hasLoopInvariantOperands(Inst) && !Inst->mayReadFromMemory() && !Inst->mayWriteToMemory() && !isa<TerminatorInst>(Inst) && !isa<DbgInfoIntrinsic>(Inst)) { Inst->moveBefore(LoopEntryBranch); continue; } The above code happily mov...

...into the preheaders of the "j-loop" and the "k-loop" respectively. I believe this is so as the operands to the GEP are loop invariant and *isSafeToExecuteUnconditionally* returns trivially true for the GEP. However, the CallInst Line 4,6 remain inside the innermost loop as the *hasLoopInvariantOperands* for the CallInsts returns false as the GEP operands themselves are not loop invariant. This is the behaviour I was not sure about and would greatly appreciate some help in understanding it. And, for LICM to hoist the CallInsts out how should the code be structured. //=== Generated IR for innermo...

Hi, I have two problems regarding the llvm.stackrestore intrinsic. I'm running on 3.0, but a quick test on trunk also showed the same behavior. First problem: --------------- I have code like: tmp1 = call llvm.stacksave() tmp2 = alloca [do some stuff with tmp2] call llvm.stackrestore(tmp1) [some other stuff] tmp3 = call llvm.stacksave() tmp4 = alloca [do some stuff