search for: licm

...roblem is that we won't vectorize the loop because the loop vectorizer does not grok the independence of a[i] and a[0] (note that i starts at 1 in this loop). While we can probably fix the vectorizer to handle this, I don't think that is the right place for the fix, because this is really a LICM problem. LICM could move a[0] out of the loop, but it currently doesn't (which is pretty suboptimial in itself). The reason is that LICM does not use SE (either directly or indirectly), and BasicAA does not recognize that a[0] and a[i] will never overlap in this loop. I see several possible so...

...roblem is that we won't vectorize the loop because the loop vectorizer does not grok the independence of a[i] and a[0] (note that i starts at 1 in this loop). While we can probably fix the vectorizer to handle this, I don't think that is the right place for the fix, because this is really a LICM problem. LICM could move a[0] out of the loop, but it currently doesn't (which is pretty suboptimial in itself). The reason is that LICM does not use SE (either directly or indirectly), and BasicAA does not recognize that a[0] and a[i] will never overlap in this loop. > > I see several p...

On 07/30/2013 09:44 PM, Chris Lattner wrote: > > On Jul 30, 2013, at 10:19 AM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > >> The pro for running LICM early is that it may move big redundant stuff out of loop nest. You never know >> how big it is. In case you are lucky , you can move lot of stuff out of >> loop, the loop may become much smaller and hence enable lots of downstream optimizations. This sound >> to be a big win for...

...roblem is that we won't vectorize the loop because the loop vectorizer does not grok the independence of a[i] and a[0] (note that i starts at 1 in this loop). While we can probably fix the vectorizer to handle this, I don't think that is the right place for the fix, because this is really a LICM problem. LICM could move a[0] out of the loop, but it currently doesn't (which is pretty suboptimial in itself). The reason is that LICM does not use SE (either directly or indirectly), and BasicAA does not recognize that a[0] and a[i] will never overlap in this loop. >> >> I see s...

Hi, I am using LLVM 2.4 on a Linux RHEL5 machine. I was trying to figure out how the chaining of the alias analysis passes works in LLVM. Here are the command I used to test the chaining part. 1. ./opt hello_world_1_nest_func.bc -o hello_world_1_nest_func_AA.bc -no-aa -anders-aa -licm Result: Anderson's AA and No Alias Analysis both are called. 2. ./opt hello_world_1_nest_func.bc -o hello_world_1_nest_func_AA.bc -basicaa -anders-aa -licm Result: Anderson's AA and Basic AA both are called. 3. ./opt hello_world_1_nest_func.bc -o hello_world_1_nest_func_AA.bc -basic...

Hi, I'm writing a new loop pass, and has a need to call LICM(Loop Invariant Code Motion) 'PromoteAliasSet' on modified loop. For now I didn't found any why to call 'PromoteAliasSet' from my pass explicitly. The only way is to schedule LICM pass after my pass. For some reason my pass need more control and preferring to call LICM 'Pr...

One way you could go is to expose the interface in include/llvm/Transforms/Utils/LoopUtils.h. There's a similar approach in the LCSSA and LoopSimplify passes, both define functions used by other passes (e.g LoopUnroll and LICM). On Fri, Dec 19, 2014 at 10:58 PM, Philip Reames <listmail at philipreames.com> wrote: > I've come across similar use cases recently. In particular, there are some > cases where I'd like run HoistRegion on a particular basic block after loop > unswitching. > > I woul...

I am studying the Transform/Scalar/LICM.cpp pass, and wrote a simple test program to validate. void testLICM(void){ int i,N=100; int data; for(i=0;i<N;i++){ data = 1; printf("i: %d\n",i); } printf("data: %d\n", data); } I expect the "data=1" will be moved out of loop (either h...

I am trying to add an analysis pass as a FunctionPass, and let LICM (LoopPass) depends upon it. So in LICM.cpp, I have the following: virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.setPreservesCFG(); AU.addRequired<DominatorTree>(); AU.addRequired<LoopInfo>(); AU.addRequiredID(LoopSimplifyID); AU.addR...

On 7/31/13 4:30 PM, Tobias Grosser wrote: > On 07/30/2013 09:44 PM, Chris Lattner wrote: >> >> On Jul 30, 2013, at 10:19 AM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: >> >>> The pro for running LICM early is that it may move big redundant >>> stuff out of loop nest. You never know >>> how big it is. In case you are lucky , you can move lot of stuff >>> out of >>> loop, the loop may become much smaller and hence enable lots of >>> downstream opti...

----- 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 'upper[j]' is not dominating exit block as its appearing > in second operand of logical AND operator. > > Prior to hoisting it check for condition in 'isGuar...

I don't think licm looks at loads/stores to allocas -- these are usually handled by mem2reg which happens much earlier (if you run your example with -mem2reg you'll see it already deleted the store). In fact, licm sinks the stores by converting them to stores to allocas first and running mem2reg on that. If you...

I'm attempting to add some support for hoisting/sinking of memory-using intrinsics in loops, and so I want to use MemoryDependenceAnalysis in LICM, but when I modify getAnalysisUsge to include this : virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.setPreservesCFG(); AU.addRequired<DominatorTree>(); AU.addRequired<LoopInfo>(); AU.addRequiredID(LoopSimplifyID); AU.addRequired<Mem...

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

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

Hi, On 02/10/2016 01:23 AM, haicheng at codeaurora.org wrote: > Thank you, Mikael. I can reproduce what you saw and am looking into it. Great! > Just curious, why do you run loop-deletion before licm and loop-idiom? As part of our internal testing we use Csmith to generate C-programs and then we run the compiler with random generated compiler flags on that input. This bug was triggered in one of those runs, so the options to opt are not something we use in our normal pipeline, but used to...

On 7/30/13 7:35 AM, Krzysztof Parzyszek wrote: > On 7/29/2013 6:28 PM, Andrew Trick wrote: >> >> You mean that LICM and Unswitching should be left for later? For the >> purpose of exposing scalar optimizations, I'm not sure I agree with >> that but I'd be interested in examples. > > Optimizations like LICM, and unswitching can potentially damage > perfect nesting of loops. For ex...

...y = v1[1]; float z = v2[1]; res = x * 0.67 + y * 0.17 + z * 0.16; t[i] = res; } return res; } $clang -emit-llvm -c myalias.cc -o myalias.bc Clearly each argument has attribute 'noalias' in LLVM IR. I plan to use basicaa and licm to hoist all load/store of x/y/z and res to ahead of loop. $ opt -basicaa -licm -print-alias-sets myalias.bc -o myalias.opt.bc -stats -debug-only=licm LICM hoisting to entry: %1 = load float** %v0.addr, align 8 LICM hoisting to entry: %arrayidx = getelementptr inbounds float* %0, i64 1 LI...

Hi, I wanted to give a heads-up that I've been looking into replacing the AliasSetTracker(AST) with MemorySSA in the Loop Invariant Code Motion (LICM) pass. I would love to get feedback on the best way to incrementally push in this change. Motivation: There has been an outstanding issue with using the Alias Set Tracker due to its expensive construction time (quadratic). We've had test cases take forever to compile, where the largest time wa...

Hi Stefanos, Thanks for your comments. I added both as reviewer. > One question though. Are you sure that this: > This helps with LICM when instructions inside a conditional is loop invariant  > is not achieved with the current LoopRotate pass? Because AFAIK, it does. Basically it inserts > a guard (that branches to the preheader) and then passes like LICM hoist invariant instructions to the preheader. > Also, it does its...