Displaying 3 results from an estimated 3 matches for "r143093".
Did you mean:
1143093
2012 Feb 03
1
[LLVMdev] Issues with the llvm.stackrestore intrinsic - now LoopRotation handling of alloca
...oca instructions be cloned rather than moved? And maybe
> there are other instructions with side effects that also should be cloned.
I haven't read your description very carefully, but your analysis
looks roughly correct; we've had similar issues with
stacksave/stackrestore before. See r143093, for example.
-Eli
2012 Feb 03
0
[LLVMdev] Issues with the llvm.stackrestore intrinsic - now LoopRotation handling of alloca
Hi,
I've tracked the first problem (mentioned in my previous email, quoted
below) down further, ending up in the handling of alloca in
LoopRotation.cpp (from trunk):
// If the instruction's operands are invariant and it doesn't read
or write
// memory, then it is safe to hoist. Doing this doesn't change the
order of
// execution in the preheader, but does
2012 Feb 01
3
[LLVMdev] Issues with the llvm.stackrestore intrinsic
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