similar to: [LLVMdev] LICM ilist question.

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

Thanks for the tip! I looked into it and it looks like the problem as of SVN HEAD is that the lui and ori instructions in Mips are considered cheap (1-cycle def-use latency) by MachineLICM::IsCheapInstruction(), but are not trivially materializable because their register operands are not always available. This makes MachineLICM::IsProfitableToHoist() return false, preventing the hoist even

Yes machine-licm can and should hoist constant materialization instructions out of the loop. If it's not doing that, it's probably because the target is not modeling the instruction correctly. I would walk through MachineLICM::IsLoopInvariantInst() in the debugger to figure it out. You can also try compiling the same bitcode for a target like ARM or X86 as a comparison. Evan On Mar 7,

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

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

Hi All, I work on a backend for a target similar to Mips, where large immediates are loaded into registers with 2 instructions, 1 to load the MSBits and 1 to load the LSBits. I've noticed a recurring pattern where, despite low register pressure, these constants will be rematerialized in every iteration of a loop, rather than being hoisted. Here's an example using the

my changed code. namespace { class MyLoopPass:public LoopPass { bool changed; public: static char ID; Loop* curLoop; // AnalysisType* AA; DominatorTree* DT; LoopInfo* LI; MyLoopPass() : LoopPass(ID){} bool isLoopInvariantInst(Instruction &I) ; bool runOnLoop(Loop * L, LPPassManager &lpm); virtual void getAnalysisUsage(AnalysisUsage &AU) const {

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

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. Does anybody have an idea why I'm getting the error below when using llc with arguments -O1 -disable-cgp? Note that this error is not given when using llc -O0. (I'd like to mention also I'm using custom Instruction selection for BUILD_VECTOR, which gets converted in my back end's machine instrution VLOAD_D, although the custom code seems to always select

----- Original Message ----- > From: "Ashutosh Nema" <Ashutosh.Nema at amd.com> > To: "songlh" <songlh at cs.wisc.edu>, llvmdev at cs.uiuc.edu > Sent: Wednesday, February 11, 2015 3:20:27 AM > Subject: Re: [LLVMdev] question about licm > > Hi, > > LICM can only hoist instructions which dominates all loop exit > blocks. > In this case

I'm current facing an issue related to AliasSetTracker/LICM: the transitive closure of the alias sets is materially more conservative than individual aliasing queries and this conservatism leads to generally worse optimization in LICM. For instance, consider this module: declare i32 @only_reads() readonly declare void @escape(i32*, i32*, i32*) define void @f(i32 %count) { entry: %a =

Hi all, I just noticed that LICM does not hoist/sink the following store out of the loop: int array[20]; int i; for (i = 0; i<100; i++) { array [0] = 0; } The getElementPtr instruction is hoisted out of the loop; the store is not. Did I miss something obvious? Bitcode file attached. Generated using LLVM 2.5 and llvm-gcc -c -emit-llvm

Hi Daniel, Thanks for the info. I’ve started looking into converting EarlyCSE to use MemorySSA first since 1) I don’t think it needs any additional MemorySSA update API and 2) the particular case I’m looking at needs EarlyCSE to catch more load cases before LICM to be profitable. I have a prototype working, but have run into two issues: 1) readonly calls are treated as clobbers by

There was some discussion a while back about adding a C++0x-style memory model and atomics for LLVM a while back (http://thread.gmane.org/gmane.comp.compilers.llvm.devel/31295), but it got stalled. I'm going to try and restart progress on it. Attached are two patches; the first adds a section to LangRef with just the memory model, without directly changing the documentation or implementation

On Oct 27, 2009, at 9:26 AM, Nick Lewycky wrote: > 2009/10/27 Marc Brünink <marc at bruenink.de> > Hi all, > > I just noticed that LICM does not hoist/sink the following store out > of the loop: > > int array[20]; > int i; > for (i = 0; i<100; i++) { > array [0] = 0; > } > > The getElementPtr instruction

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

Hi All, I'm looking into converting LICM to use MemorySSA instead of AliasSets to determine when it is safe to hoist/sink/promote loads and stores to get around the issue of alias set collapse (see discussion [1]). I have a prototype implementation, but have run into two issues that I could use input from the designers of MemorySSA to resolve: 1) Is MemorySSA intended to be

Hi everyone, The MachineLICM pass has a heuristic such that, even in low-register-pressure situations, it will refuse to hoist "cheap" instructions out of loops. By default, when an itinerary is available, this means that all of the defined operands are available in at most 1 cycle. ARM overrides this, and provides this more-customized definition: bool ARMBaseInstrInfo::