similar to: [LLVMdev] A question about LICM (Loop Invariant Code Motion)

Hi Yuelu, > 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: the function

On Tue, Feb 8, 2011 at 4:55 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Yuelu, > >> 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 >>

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

I am using LLVM 2.6 and I have a question on the use of the BasicBlock::iterator to hoist loop invariant instructions to the loop preheader. When I process the instructions backward as shown in the following code, I got the following error right after the "hoist(I)" is done. Can anyone advise whether I am misusing BasicBlock::iterator? /opt/llvms/src/llvm_26/

Hi Gang-Ryung! Your reverse iteration of instructions in the BB > * for (BasicBlock::iterator II = BB->end(); II != BB->begin(); ) *{ > > Instruction &I = *--II; > > if (isLoopInvariantInst(I) && canSinkOrHoistInst(I) && > isSafeToExecuteUnconditionally(I)) > * hoist(I);* >

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

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 safe to speculatively execute. The

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

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

Hey all, I was doing some investigation of LICM and I ran into something that seems a bit odd to me. Suppose I was looking at the following code snippet: #define N 1000 int main() { int B[N]; char A[N]; for(int i=0; i<N; i++) { B[i] = strlen(A); } return B[0]+B[N-1]; } Among other optimizations that I may want to happen, I'd hope that the call to strlen could be

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

Hi, A few days ago I stumbled upon a problem where SpeculativeExecution changed the order of a load and a store to the same 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

Hello, I am working on a C++ expression templates based DSL where we are using LLVM for the code generation. I needed some help in understanding the behaviour of the LICM pass. In the following example code the "A" class is a custom container that defines various arithmetic operators using expression templates. We are defining three arrays of the "A" container and aggregating

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

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