similar to: [LLVMdev] Decouple LoopVectorizer from O3

Hi Nadav, I tried your suggestion by changing the condition to : 189 if (LoopVectorize && OptLevel >= 0) 190 MPM.add(createLoopVectorizePass()); and compiled. Then I used the following command: opt -mtriple=x86_64-linux-gnu -vectorize-loops -vectorizer-min-trip-count=6 -debug-only=loop-vectorize -O1-S -o example1_vect.s example1.s where example1.s is IR generated by clang -S

Done. Best, Anadi. On Thu, Apr 11, 2013 at 7:01 AM, Nadav Rotem <nrotem at apple.com> wrote: > Hi Anadi, > > Yes, this is a bug in the loop vectorizer. The loop vectorizer expects only > one loop counter (integer with step=1). There is no reason why we should > not handle the case below, and it should be easy to fix. Interestingly > enough if you reverse the order of

Just an FYI: it's often handy to mention the PR number when a thread is concluded by filing a bug. That way other people reading (now, or more importantly, later) can follow the issue through to the bug and its resolution On Apr 11, 2013 4:24 PM, "Anadi Mishra" <reachanadi at gmail.com> wrote: > Done. > > Best, > Anadi. > > > On Thu, Apr 11, 2013 at 7:01

Hi Anadi, Yes, this is a bug in the loop vectorizer. The loop vectorizer expects only one loop counter (integer with step=1). There is no reason why we should not handle the case below, and it should be easy to fix. Interestingly enough if you reverse the order of iterations and count from SIZE to zero, the loop vectorizer would vectorize it. If you open a bugzilla report and assign it to me

Hi Anadi, In the file PassManagerBuilder.cpp you can change the lines below to get rid of the O3 restriction. 189 if (LoopVectorize && OptLevel > 2) 190 MPM.add(createLoopVectorizePass()); Nadav On Apr 10, 2013, at 5:39 PM, Anadi Mishra <reachanadi at gmail.com> wrote: > Hello, > > I am trying out the LoopVectorizer(LV) pass and would like to decouple

Thanks for the suggestion Jim. I already tried to do it by 'opt' but it also requires O3. BTW I think that if I invoke 'opt' with '-vectorize-loops' option, it will figure out the passes required for LV since every pass mentions what other passes are prerequisite. Am I correct? Best, Anadi. On Thu, Apr 11, 2013 at 2:48 AM, Jim Grosbach <grosbach at apple.com>

You can take unoptimized bitcode and run it through ‘opt’ to have complete flexibility in which passes get run. It may take some fiddling to find out the pass sequence and ordering that does what you want, as some passes rely on previous passes to canonicaplize code into a form it can effectively work with. -Jim On Apr 10, 2013, at 5:39 PM, Anadi Mishra <reachanadi at gmail.com> wrote:

Hello, I am trying to vectorize the following loop but the vectorizer says: "Found a possible write-write reorder" and does not vectorize. Why? for (j=0; j < 8; j++) { jj = j << 3; m2[j][0] = diff[jj ] + diff[jj+4]; m2[j][1] = diff[jj+1] + diff[jj+5]; m2[j][2] = diff[jj+2] + diff[jj+6]; m2[j][3] = diff[jj+3] + diff[jj+7]; m2[j][4] = diff[jj ] -

On Wed, Apr 17, 2013 at 8:08 AM, Tobias Grosser <tobias at grosser.es> wrote: > On 04/17/2013 04:55 AM, Anadi Mishra wrote: >> >> Hello, >> >> I am trying to vectorize the following loop but the vectorizer says: >> "Found a possible write-write reorder" and does not vectorize. >> Why? > > > To my knowledge, the dependence analysis in

I think this has to do with how the pass manager is populated when we give -O3 vs when we give particular pass names. Some passes have multiple createXYZPass() methods that accept arguments too. These methods call non-default pass constructors, which in turn cause the passes to behave in a different manner. eg: Pass *llvm::createLICMPass() { return new LegacyLICMPass(); } Pass

On 04/17/2013 04:55 AM, Anadi Mishra wrote: > Hello, > > I am trying to vectorize the following loop but the vectorizer says: > "Found a possible write-write reorder" and does not vectorize. > Why? To my knowledge, the dependence analysis in the loop vectorizer is not yet able to prove the absence of dependences here. > for (j=0; j < 8; j++) > { > jj

Dear developers, I am trying to reproduce the results of applying opt -O3 to a source file in the form of LLVM IR. I want to get the same IR by manually ordering the passes used by O3 and passing them to opt. To illustrate what I am doing on an example, as an input I use linpack benchmark from the LLVM test suite[1]: 1. First I produce the intermediate representation using clang: clang -O3

On 01/25/2013 04:00 PM, Hal Finkel wrote: > Based on this experience, can you propose some metadata that would allow > this to happen (so that the LoopVectorizer would be generally useful for > POCL)? I suspect this same metadata might be useful in other contexts (such > as implementing iteration-independence pragmas). I cannot yet. In this hack I simply changed LoopVectorizer to

Hi Ralf, On 01/31/2013 05:44 PM, Ralf Karrenberg wrote: > As for the current status, the loop vectorizer is only able to vectorize > inner loops and (I think) does not handle function calls and memory > operations well. This will prevent it from vectorizing a large group of > OpenCL kernels, and certainly all "interesting", more complex ones. Agreed -- but not being able to

> I am in favor of adding metadata to control different aspects of > vectorization, mainly for supporting user-level pargmas [1] but also for > DSLs. Before we start adding metadata to the IR we need to define the > semantics of the tags. "Parallel_for" is too general. We also want to control > vectorization factor, unroll factor, cost model, etc. These are used to

Hi, Attached is a patch which uses a simple "parallel_loop" metadata attached to the loop branch instruction in the loop latch for skipping cross-iteration memory dependency checking in the LoopVectorizer. This was briefly discussed in the email thread "LoopVectorizer in OpenCL C work group autovectorization". It also converts the "min iteration count to vectorize"

Hi Pekka, hi Nadav, I didn't find the time to read this thread until now, sorry for that. I actually think you are both right :). As for the current status, the loop vectorizer is only able to vectorize inner loops and (I think) does not handle function calls and memory operations well. This will prevent it from vectorizing a large group of OpenCL kernels, and certainly all

----- Original Message ----- > From: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi> > To: "Nadav Rotem" <nrotem at apple.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, January 25, 2013 5:35:16 AM > Subject: Re: [LLVMdev] LoopVectorizer in OpenCL C work group autovectorization > > On

Hi All, I have got one domination error after running LoopVectorizer with VPlanNatviePath. Let's see simple IR snippet after loop vectorization with VPlanNatviePath. vector.body: ... br label %for.body10.preheader67 for.body10.preheader67: ; preds = %for.cond.cleanup972, %vector.body %vec.phi = phi <4 x i64> [ zeroinitializer, %for.cond.cleanup972 ], [ %8,

On 01/25/2013 09:56 AM, Nadav Rotem wrote: > Thanks for checking the Loop Vectorizer, I am interested in hearing your > feedback. The Loop Vectorizer does not fit here. OpenCL vectorization is > completely different because the language itself is data-parallel. You > don't need all of the legality checks that the loop vectorizer has. I'm aware of this and it was my point in