similar to: [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

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

Kuperstein, Michael M wrote: > A patch is attached. + const CallInst* CI = dyn_cast<CallInst>(Inst); + return CI->isSafeToSpeculativelyExecute(); "return cast<CallInst>(Inst)->isSafeToSpeculativelyExecute();"? Use cast<> instead of dyn_cast<>. See http://llvm.org/docs/ProgrammersManual.html#isa . Then I don't think it needs to be two lines.

A patch is attached. Not sure I'm happy with this due to the aforementioned orthogonality concerns, but I really don't have any better ideas. If anyone does, feel free to offer them, I don't mind throwing this patch into the trash. (Also, not happy with the name, using "speculatable" as Nick suggested, for the lack of other options. If the name stays I'll add it to the

On 22 July 2013 01:11, Kuperstein, Michael M <michael.m.kuperstein at intel.com > wrote: > Of course frontends are free to put attributes, but it would be nice if > optimizations actually used them. ;-) > My use case is that of proprietary frontend that happens to know some > library function calls - which are only resolved at link time - have no > side effects and are safe

Right, will fix the CallInst, copy/pasted from a different case and didn't notice what I was doing, thanks. Re LangRef.rst, that's what I meant, I'm still hoping for better suggestions regarding the name... As to the conflict - Tobias, feel free to go first, I'll merge. -----Original Message----- From: Nick Lewycky [mailto:nicholas at mxc.ca] Sent: Thursday, July 25, 2013 12:11

Hello, Chris requested I start a fresh discussion on this, so, here goes. The previous iterations can be found here (and in follow-ups): http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130722/182590.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/064047.html Cutting to the chase, the goal is to enhance llvm::isSafeToSpeculativelyExecute() to support call instructions.

Of course frontends are free to put attributes, but it would be nice if optimizations actually used them. ;-) My use case is that of proprietary frontend that happens to know some library function calls - which are only resolved at link time - have no side effects and are safe to execute speculatively, and wants to tell the optimizer it can move them around however it likes. I'll gladly submit

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

Hi, I recently looked into the LICM(Loop Invariant Code Motion) pass of LLVM and got a question about hoist load instruction to loop preheader. I would like to show two examples: Example 1: int func(int n, int *fp) { int i; int a[1000]; for (i = 0; i < n; ++i) { a[i] += *fp; // load from *fp pointer, no hoist } } Here, load *fp CAN NOT be hoisted to loop preheader. If replace *fp

On Aug 21, 2009, at 8:46 PM, Eli Friedman wrote: > On Fri, Aug 21, 2009 at 3:29 PM, Jakub Staszak<kuba at gcc.gnu.org> > wrote: >> >> On Aug 21, 2009, at 7:31 PM, Eli Friedman wrote: >> >>> On Fri, Aug 21, 2009 at 2:06 PM, Jakub Staszak<kuba at gcc.gnu.org> >>> wrote: >>>> >>>> Hello, >>>>

On Aug 21, 2009, at 10:02 PM, Eli Friedman wrote: > On Fri, Aug 21, 2009 at 4:53 PM, Jakub Staszak<kuba at gcc.gnu.org> > wrote: >> >> On Aug 21, 2009, at 8:46 PM, Eli Friedman wrote: >> >>> On Fri, Aug 21, 2009 at 3:29 PM, Jakub Staszak<kuba at gcc.gnu.org> >>> wrote: >>>> >>>> On Aug 21, 2009, at 7:31 PM, Eli

On Aug 21, 2009, at 10:27 PM, Eli Friedman wrote: > On Fri, Aug 21, 2009 at 5:05 PM, Jakub Staszak<kuba at gcc.gnu.org> > wrote: >> >> On Aug 21, 2009, at 10:02 PM, Eli Friedman wrote: >> >>> On Fri, Aug 21, 2009 at 4:53 PM, Jakub Staszak<kuba at gcc.gnu.org> >>> wrote: >>>> >>>> On Aug 21, 2009, at 8:46 PM, Eli

On Fri, Aug 21, 2009 at 5:47 PM, Jakub Staszak<kuba at gcc.gnu.org> wrote: > > On Aug 21, 2009, at 10:27 PM, Eli Friedman wrote: > >> On Fri, Aug 21, 2009 at 5:05 PM, Jakub Staszak<kuba at gcc.gnu.org> wrote: >>> >>> On Aug 21, 2009, at 10:02 PM, Eli Friedman wrote: >>> >>>> On Fri, Aug 21, 2009 at 4:53 PM, Jakub Staszak<kuba at

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

On Fri, Aug 21, 2009 at 4:53 PM, Jakub Staszak<kuba at gcc.gnu.org> wrote: > > On Aug 21, 2009, at 8:46 PM, Eli Friedman wrote: > >> On Fri, Aug 21, 2009 at 3:29 PM, Jakub Staszak<kuba at gcc.gnu.org> wrote: >>> >>> On Aug 21, 2009, at 7:31 PM, Eli Friedman wrote: >>> >>>> On Fri, Aug 21, 2009 at 2:06 PM, Jakub Staszak<kuba at

On Fri, Aug 21, 2009 at 5:05 PM, Jakub Staszak<kuba at gcc.gnu.org> wrote: > > On Aug 21, 2009, at 10:02 PM, Eli Friedman wrote: > >> On Fri, Aug 21, 2009 at 4:53 PM, Jakub Staszak<kuba at gcc.gnu.org> wrote: >>> >>> On Aug 21, 2009, at 8:46 PM, Eli Friedman wrote: >>> >>>> On Fri, Aug 21, 2009 at 3:29 PM, Jakub Staszak<kuba at

Hi, All CallInsts should return true for Instruction::mayHaveSideEffects() because functions are not guaranteed to halt. Inliner::runOnSCC calls isInstructionTriviallyDead to determine whether code can be dead code eliminated. isInstructionTriviallyDead returns true if Instruction::mayHaveSideEffects() returns false. A function that potentially runs forever based on its input but does not write

Hello, For the Glasgow Haskell Compiler's backend, we would like 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

----- Original Message ----- > From: "Philip Reames" <listmail at philipreames.com> > To: "Thomas F Raoux" <thomas.f.raoux at intel.com>, llvmdev at cs.uiuc.edu > Sent: Tuesday, July 14, 2015 11:59:49 PM > Subject: Re: [LLVMdev] LICM for function calls > > On 07/14/2015 07:45 AM, Raoux, Thomas F wrote: > > Hi, > > > > Right now