similar to: Metadata and compile time performance

Hi all, Sorry if this is a dumb or FAQ or the wrong list! I'm currently investigating LLVM vectorization of my generated code. My codegen emits a lot of recursions that step through arrays via pointers. The recursions are nicely optimized into loops, but the loop vectorization can't seem to work on them because of phi nodes that point to gep nodes. Some simple IR to demonstrate; it

Hi Vesa, The pass IndVars changes the induction variables to allow SCEV to analyze them and enable other optimizations. This is the canonicalization phase. Later on, LSR lowers the canonicalized induction variables to induction variables that map nicely to the target's addressing modes. In many cases it can remove some of the induction variables. I suspect that the loop vectorizer does

Dear alltogether, how can a delay like possible with par(ask=TRUE) be attained while using trellis-plots within a loop or something like that? the following draws each plot without waiting for a signal (mouse-klick), so par() does not work for that: library(nlme) for(i in 1:3) { fitlme <- lme(Orthodont) par(ask=TRUE) # does not work with trellis.... print(

add -basicaa to your command line :) On Mon, May 11, 2015 at 7:15 AM, Willy WOLFF <willy.mh.wolff at gmail.com> wrote: > I play a bit more with MemoryDependenceAnalysis by wrapping my pass, and > call explicitely BasicAliasAnalysis. Its still using No Alias Analysis. > > How can I let MemoryDependenceAnalysis use BasicAliasAnalysis? > > Please, find attached my pass. >

----- Original Message ----- > From: "Vesa Norilo" <vnorilo at siba.fi> > To: llvmdev at cs.uiuc.edu > Sent: Tuesday, February 19, 2013 4:40:26 AM > Subject: [LLVMdev] Auto-vectorization and phi nodes > > Hi all, > > Sorry if this is a dumb or FAQ or the wrong list! > > I'm currently investigating LLVM vectorization of my generated code. > My

Hi, I try to use MemoryDependenceAnalysis in a pass to analyse a simple function: void fct (int *restrict*restrict M, int *restrict*restrict L) { S1: M[1][1] = 1; S2: L[2][2] = 2; } When I iterate over MemoryDependenceAnalysis on the S2 statement, I get the load instruction for the first depth of the array, that’s ok. But I get also the load and store for the S1 statement. I assume the

Hi there, I am doing: opt -print-memdeps ./test.bc -analyze -globalsmodref-aa by adding globalsmodref-aa, I am hoping that globalsmodref alias analysis will be used. However, it does not turn out to be so. I found this out by adding some "errs() << " into the source code for that alias analysis. So my question is what should I do to let memory dependency analysis use

On Feb 19, 2013, at 10:09 AM, Vesa Norilo <vnorilo at siba.fi> wrote: > Hi Nadav and Hal and thanks for the help! > > To the best of my understanding, indvars doesn't complain and an induction variable is detected. However, the loop vectorizer says: > > LV: Checking a loop in "add_vector" > LV: Found a loop: Loop > LV: Found an induction variable. >

I think it would make sense for (1) and (2). I am not sure if (3) is feasible in instcombine. (I am not too familiar with LoopInfo) For the Octasic's Opus platform, I modified shouldMergeGEPs in our fork to: if (GEP.hasAllZeroIndices() && !Src.hasAllZeroIndices() && !Src.hasOneUse()) return false; return Src.hasAllConstantIndices(); // was return false;

Hi Nadav and Hal and thanks for the help! To the best of my understanding, indvars doesn't complain and an induction variable is detected. However, the loop vectorizer says: LV: Checking a loop in "add_vector" LV: Found a loop: Loop LV: Found an induction variable. LV: Found an unidentified PHI. %a.ptr = phi float* [ %a, %Top ], [ %a.next, %Loop ] LV: Can't vectorize the

LLVMers, I am doing a CallGraphPass but would like to get the LoopInfo of the functions inside this pass, is this possible? Currently I have a function inside the CallGraph struct: void getAnalysisUsage(AnalysisUsage &AU) const { AU.addRequired<LoopInfo>(); AU.addPreserved<LoopInfo>(); } And later inside the pass I am calling: LoopInfo &LI =

Dear LLVM developers, I am Shen, a PhD student at Lehigh Univ. PA. Now I am implementing a Program Dependence Graph(PDG) on LLVM. I have 4 passes here: 1. ProgramDependenceGraph (a *ModulePass *on the highest level) 2. DataDependenceGraph (a Intermediate *FunctionPass*). 3. FlowDependenceAnalysis Pass (a intermediate *FunctionPass*) which uses llvm built-in AliasAnalysis (-basicaa) 4.

Hi, Richard, Your decompose vector patch works perfect on my site. Unfortunately, I still get stupid code because llvm '-dse' fails followed by 'decompose-vector' . I read the DSE code and it is definitely capable of eliminating unused memory stores if its AA works. I don't think basic AA works for me. I found my program have complex memory accesses, such as bi-dimentional

> Not everyone thinks that such a thing would be bonware [1]. > Regards, > Nate > [1] http://en.windows7sins.org/ Probably shouldn't feed this any more, but.. I work primarily with Visual Studio and LLVM myself and have absolutely no objection to dropping VS2010. In fact, I stronly support such a move, as the VC++ compiler has improved quite a bit recently, especially in the

On 11/10/11 11:48 AM, Ryan Taylor wrote: > John, > > Thanks, this does not compile though, I get this error: First, please CC the llvmdev list. That way, others having the same question can see the conversation, and others on the list can help correct any errors I make. :) > > cdfg_pass.cpp:511:11: error: ‘class llvm::Function’ has no member > named ‘getDeclaration’

----- Original Message ----- > From: "Jingyue Wu" <jingyue at google.com> > To: "songlh" <songlh at cs.wisc.edu>, llvmdev at cs.uiuc.edu > Sent: Wednesday, October 15, 2014 2:50:12 PM > Subject: Re: [LLVMdev] how to choose which alias analysis used in my pass? > > > Isn't -basicaa the default alias analysis already? No, -basicaa is added

John, This did not work. It compiles (isDeclaration was the name of the function) and I passed a reference (&F) (F is a function pointer). I still get the opt load error from the original message (UNREACHABLE exectuted!). Thanks. On Thu, Nov 10, 2011 at 10:00 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > 1. Ok will do. > 2. Ok, will do. > 3. It's a CallGraphPass. I

Liu Xin <navy.xliu at gmail.com> writes: > Your decompose vector patch works perfect on my site. Unfortunately, I > still get stupid code because llvm '-dse' fails followed by > 'decompose-vector' . > I read the DSE code and it is definitely capable of eliminating unused > memory stores if its AA works. I don't think basic AA works for me. I > found

Hi Mark, It is not clear to me at all that preventing the merging is the right solution. There are a large number of analysis, including alias analysis, and optimizations that use GetUnderlyingObject, and related routines to search back through GEPs. They only do this up to some small finite depth (six, IIRC). So reducing the GEP depth is likely the right solution for InstCombine (which has the

1. Ok will do. 2. Ok, will do. 3. It's a CallGraphPass. I mentioned this in my first post. 4. Yep, I have the header files included, I'm not sure it would compile otherwise (previously). I would get an error like LoopInfo not declared. I'll try your suggestions, thanks again! On Thu, Nov 10, 2011 at 9:57 AM, John Criswell <criswell at illinois.edu>wrote: > On 11/10/11