search for: issafetospeculativelyexecute

Displaying 20 results from an estimated 58 matches for "issafetospeculativelyexecute".

2009 Aug 21
1
[LLVMdev] PR4174
...gt; >>> wrote: >>>> >>>> Hello, >>>> >>>> This patch fixes PR4174. Two test-cases included: original one from >>>> bugzilla >>>> and a little bit complicated made be myself. >>> >>> I think you want isSafeToSpeculativelyExecute rather than >>> mayHaveSideEffects. Otherwise, looks fine. >> >> With isSafeToSpeculativelyExecute "make check" fails on some tests, >> i.e: >> test/Transforms/LoopIndexSplit/SaveLastValue-2007-08-17.ll >> because of PHI (isSafeToSpeculativelyExec...
2009 Aug 22
2
[LLVMdev] PR4174
...; This patch fixes PR4174. Two test-cases included: original >>>>>>>> one from >>>>>>>> bugzilla >>>>>>>> and a little bit complicated made be myself. >>>>>>> >>>>>>> I think you want isSafeToSpeculativelyExecute rather than >>>>>>> mayHaveSideEffects. Otherwise, looks fine. >>>>>> >>>>>> With isSafeToSpeculativelyExecute "make check" fails on some >>>>>> tests, >>>>>> i.e: >>>>>> test...
2009 Aug 22
2
[LLVMdev] PR4174
...>>>> >>>>>> This patch fixes PR4174. Two test-cases included: original one >>>>>> from >>>>>> bugzilla >>>>>> and a little bit complicated made be myself. >>>>> >>>>> I think you want isSafeToSpeculativelyExecute rather than >>>>> mayHaveSideEffects. Otherwise, looks fine. >>>> >>>> With isSafeToSpeculativelyExecute "make check" fails on some >>>> tests, i.e: >>>> test/Transforms/LoopIndexSplit/SaveLastValue-2007-08-17.ll >>&g...
2009 Aug 22
0
[LLVMdev] PR4174
...>>>>> This patch fixes PR4174. Two test-cases included: original one from >>>>>>>>> bugzilla >>>>>>>>> and a little bit complicated made be myself. >>>>>>>> >>>>>>>> I think you want isSafeToSpeculativelyExecute rather than >>>>>>>> mayHaveSideEffects.  Otherwise, looks fine. >>>>>>> >>>>>>> With isSafeToSpeculativelyExecute "make check" fails on some tests, >>>>>>> i.e: >>>>>>> test/Transf...
2009 Aug 21
3
[LLVMdev] PR4174
Hello, This patch fixes PR4174. Two test-cases included: original one from bugzilla and a little bit complicated made be myself. It seems that LoopIndexSplit doesn't handle some cases, I'll try to send some patch this week. Regards -- Jakub Staszak -------------- next part -------------- A non-text attachment was scrubbed... Name: pr4174.patch Type: application/octet-stream Size:
2009 Aug 22
0
[LLVMdev] PR4174
...t;>>> >>>>> Hello, >>>>> >>>>> This patch fixes PR4174. Two test-cases included: original one from >>>>> bugzilla >>>>> and a little bit complicated made be myself. >>>> >>>> I think you want isSafeToSpeculativelyExecute rather than >>>> mayHaveSideEffects.  Otherwise, looks fine. >>> >>> With isSafeToSpeculativelyExecute "make check" fails on some tests, i.e: >>> test/Transforms/LoopIndexSplit/SaveLastValue-2007-08-17.ll >>> because of PHI (isSafeToSpeculat...
2009 Aug 22
0
[LLVMdev] PR4174
...gt;>>>>> >>>>>>> This patch fixes PR4174. Two test-cases included: original one from >>>>>>> bugzilla >>>>>>> and a little bit complicated made be myself. >>>>>> >>>>>> I think you want isSafeToSpeculativelyExecute rather than >>>>>> mayHaveSideEffects.  Otherwise, looks fine. >>>>> >>>>> With isSafeToSpeculativelyExecute "make check" fails on some tests, >>>>> i.e: >>>>> test/Transforms/LoopIndexSplit/SaveLastValue-2007-0...
2012 Aug 19
2
[LLVMdev] isSafeToSpeculativelyExecute() for CallInst
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 s...
2012 Sep 08
0
[LLVMdev] isSafeToSpeculativelyExecute() for CallInst
On Aug 19, 2012, at 2:55 PM, "Kuperstein, Michael M" <michael.m.kuperstein at intel.com> wrote: > 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 Instructio...
2012 Sep 09
1
[LLVMdev] isSafeToSpeculativelyExecute() for CallInst
Hi Nadav, On 08/09/12 22:51, Nadav Rotem wrote: > > On Aug 19, 2012, at 2:55 PM, "Kuperstein, Michael M" > <michael.m.kuperstein at intel.com <mailto:michael.m.kuperstein at intel.com>> wrote: > >> 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 speci...
2017 May 10
4
-speculative-execution moving load before store
...ame address. I wrote https://bugs.llvm.org//show_bug.cgi?id=32964 about it but no response there so far. In the input we have store i8 0, i8* @i %.pre = load i8, i8* @i and then in the output the load is moved so it's before the store which clearly makes it load the wrong value. isSafeToSpeculativelyExecute happily says "true" for the load, and there is a comment on isSafeToSpeculativelyExecute saying /// This method can return true for instructions that read memory; /// for such instructions, moving them may change the resulting value. And that is indeed the case in PR32964. How i...
2015 Apr 24
2
[LLVMdev] Speculative loads and alignment
Hi, There are several optimizations where we try to load speculatively. There are also two similar functions to determine whether it's a safe transformation: * isSafeToLoadUnconditionally * isSafeToSpeculativelyExecute isSafeToLoadUnconditionally tries to take load alignment into account but fails to do this in some cases. It checks alignment for pointers derived from allocas and global variables. But in other cases it scans the local BB to see if the pointer is already being loaded or stored from/to. In the lat...
2011 Feb 07
3
[LLVMdev] A question about LICM (Loop Invariant Code Motion)
...lt; n; ++i) { a[i] += gv; // load from the @gv pointer, hoist } } load for the global var gv's value CAN be hoist to loop preheader. After tracking the LICM pass, I find that both loads are loop 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)) // invoke...
2010 May 11
1
[LLVMdev] All CallInsts mayHaveSideEffects
...m/Instruction.h =================================================================== --- include/llvm/Instruction.h (revision 102637) +++ include/llvm/Instruction.h (working copy) @@ -245,7 +245,9 @@ /// instructions which don't used the returned value. For cases where this /// matters, isSafeToSpeculativelyExecute may be more appropriate. bool mayHaveSideEffects() const { - return mayWriteToMemory() || mayThrow(); + const unsigned opcode = getOpcode(); + return mayWriteToMemory() || mayThrow() || + opcode == Call || opcode == Invoke; } /// isSafeToSpeculativelyExecute - Return true i...
2012 Jan 23
4
[LLVMdev] Safe loads
...to let LLVM know that certain loads are safe to execute speculatively and hence to hoist out of loops. At the moment, there doesn't seem to be a mechanism for doing so. There seem to be two ways of implementing this: either allow arbitrary instructions to be marked as safe and have Instruction::isSafeToSpeculativelyExecute return true for those or mark memory regions and extend Value::isDereferenceablePointer to return true for those. Is either of these a good idea? Or is there some other way to do this? FWIW, I quickly prototyped instruction marking using metadata and that seemed to work well enough for us. Roman
2009 Aug 21
0
[LLVMdev] PR4174
...e: > On Fri, Aug 21, 2009 at 2:06 PM, Jakub Staszak<kuba at gcc.gnu.org> > wrote: >> Hello, >> >> This patch fixes PR4174. Two test-cases included: original one from >> bugzilla >> and a little bit complicated made be myself. > > I think you want isSafeToSpeculativelyExecute rather than > mayHaveSideEffects. Otherwise, looks fine. With isSafeToSpeculativelyExecute "make check" fails on some tests, i.e: test/Transforms/LoopIndexSplit/SaveLastValue-2007-08-17.ll because of PHI (isSafeToSpeculativelyExecute == false). >> It seems that LoopIndexSplit...
2017 Mar 15
2
Speculative execution of FP divide Instructions - Call-Graph Simplify
...e %a_mul, %a3 %a_div = fdiv double %a_mul, %a3 %a_factor = select i1 %a_cmp, double %a_div, double 1.000000e+00 ret double %a_factor } ``` This will cause a FP arithmetic exception, and the application will get a SIGFPE signal. The code that drives the change in the optimizer relies on `llvm::isSafeToSpeculativelyExecute` to decide whether the division should be performed speculatively. Right now, this function returns true. One could do something similar to integer divisions and add a case there (this solved the issue for me): ``` diff --git a/lib/Analysis/ValueTracking.cpp b/lib/Analysis/ValueTracking.cpp index 1...
2010 May 11
1
[LLVMdev] All CallInsts mayHaveSideEffects
...============================================================ > --- include/llvm/Instruction.h  (revision 102637) > +++ include/llvm/Instruction.h  (working copy) > @@ -245,7 +245,9 @@ >   /// instructions which don't used the returned value.  For cases where this >   /// matters, isSafeToSpeculativelyExecute may be more appropriate. >   bool mayHaveSideEffects() const { > -    return mayWriteToMemory() || mayThrow(); > +    const unsigned opcode = getOpcode(); > +    return mayWriteToMemory() || mayThrow() || > +      opcode == Call || opcode == Invoke; >   } > >   /// isSafeToS...
2017 Mar 15
3
Speculative execution of FP divide Instructions - Call-Graph Simplify
...ctor = select i1 %a_cmp, double %a_div, double 1.000000e+00 >> ret double %a_factor >> } >> ``` >> This will cause a FP arithmetic exception, and the application will >> get a SIGFPE signal. The code that drives the change in the optimizer >> relies on `llvm::isSafeToSpeculativelyExecute` to decide whether the >> division should be performed speculatively. Right now, this function >> returns true. One could do something similar to integer divisions and >> add a case there (this solved the issue for me): >> ``` >> diff --git a/lib/Analysis/ValueTrack...
2015 Jul 14
4
[LLVMdev] LICM for function calls
Hi, Right now in LICM (and many other transformations) we always assume it is never safe to speculatively execute a function call. The following function always return false for all function calls except for few intrinsics: bool llvm::isSafeToSpeculativelyExecute(const Value *V, const DataLayout *TD) { ... case Instruction::Call: { if (const IntrinsicInst *II = dyn_cast<IntrinsicInst>(Inst)) { ... } return false; // The called function could have undefined behavior or // side-effect...