similar to: [LLVMdev] LICM

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 is hoisted out of the loop; the store is not. > Did I

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

Chris Lattner schrieb: > On Aug 21, 2009, at 3:04 AM, Marc Brünink wrote: >>> This isn't really possible. The issue is that MemDep doesn't just >>> "analyze your function". It is designed to be as lazy as possible, >>> which means that it only does analysis when a query is performed. This >>> means that if you have

On Fri, Aug 21, 2009 at 10:48 AM, Marc Brünink<marc at bruenink.de> wrote: >>> actually my problem is easier. So I still have hope that it is possible: >>> >>> MemDep->Pass1->Pass2 >>> >>> Pass1 uses MemDep. Pass2 only uses Pass1. Eventually, Pass2 changes the >>> code. Unfortunately, non-local dependencies of MemDep might point to

Hi all, I need to transform loops like this one for (int i = b; i<e; ++i) buffer[i]; into loops like this one: for(p=buffer+b; p<buffer+e; ++p) *p; Does any pass already perform this? If there's none, I guess loop-reduce is a good starting point for me, isn't it? Thanks Marc

> Has anybody debugged LLVM IR with GDB? I'm using dragonegg to transform C > into IR, then applying my optimizations. Passing "-g" to dragonegg doesn't > seem to work since it generates debug info for the C code, not the IR. I > really need GDB (lli doesn't solve my problems) in order to debug > multi-threaded and multi-process MPI code. > > More

On Thu, Oct 18, 2012 at 8:59 AM, Eli Bendersky <eliben at gmail.com> wrote: > >> Has anybody debugged LLVM IR with GDB? I'm using dragonegg to transform C >> into IR, then applying my optimizations. Passing "-g" to dragonegg doesn't >> seem to work since it generates debug info for the C code, not the IR. I >> really need GDB (lli doesn't

Chris Lattner schrieb: > > On Aug 20, 2009, at 11:44 AM, Marc Brünink wrote: > >> Hi, >> >> I do have a FunctionPass that does change the code. This FunctionPass >> requires another FunctionPass which performs all the necessary analyses. >> This AnalysisPass again requires MemoryDependenceAnalysis. >> >> The problem is, that I would like

Hi, I do have a FunctionPass that does change the code. This FunctionPass requires another FunctionPass which performs all the necessary analyses. This AnalysisPass again requires MemoryDependenceAnalysis. The problem is, that I would like MemoryDependenceAnalysis to run on the unaltered module. I do not want to have dependencies to changed code. What is the cleanest way to do this? Sounds

Hi all, Has anybody debugged LLVM IR with GDB? I'm using dragonegg to transform C into IR, then applying my optimizations. Passing "-g" to dragonegg doesn't seem to work since it generates debug info for the C code, not the IR. I really need GDB (lli doesn't solve my problems) in order to debug multi-threaded and multi-process MPI code. More clearly, if I have a file

On Aug 20, 2009, at 11:44 AM, Marc Brünink wrote: > Hi, > > I do have a FunctionPass that does change the code. This FunctionPass > requires another FunctionPass which performs all the necessary > analyses. > This AnalysisPass again requires MemoryDependenceAnalysis. > > The problem is, that I would like MemoryDependenceAnalysis to run on > the > unaltered

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 3:04 AM, Marc Brünink wrote: >> This isn't really possible. The issue is that MemDep doesn't just >> "analyze your function". It is designed to be as lazy as possible, >> which means that it only does analysis when a query is performed. >> This >> means that if you have MemDep->Pass1->Pass2 and Pass2 uses MemDep

hi, I applied licm with basicaa on the following codes: int j = atoi(argc[1]); int lower[] = {10, 9, 8, 7, 6, 5, 4, 3, 2, 1}; int upper[] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}; for(i = lower[j]; a[i] < 100 && i < upper[j]; i ++); I notice that upper[j] is not hoisted out from the loop. Is this because j could be larger than 10? Thanks a lot! Best,

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

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,

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

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

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