search for: issafetospeculativelyexecut

...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 (isSafeToSpeculativelyExe...

...; 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: >>>>>> tes...

...>>>> >>>>>> 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 >>&...

...>>>>> 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/Trans...

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:

...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 (isSafeToSpecula...

...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-...

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...

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 Instructi...

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 spec...

...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...

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 la...

...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)) // invok...

...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...

...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

...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 LoopIndexSpli...

...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...

...============================================================ > --- 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; >   } > >   /// isSafeTo...

...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/ValueTrac...

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-effec...