search for: bbvectorizer

Hi Everyone, I propose that we remove BBVectorize from trunk. Here's why: - It never made it from "interesting experiment" to "production quality" (it is not part of any in-tree optimization pipeline). - We now have an SLP vectorizer that we do use in production, had have for some time. - BBVectorize otherwise needs refactoring, and the implementation has lots of

...); +    }     virtual void getAnalysisUsage(AnalysisUsage &AU) const {       BasicBlockPass::getAnalysisUsage(AU); @@ -1861,3 +1871,8 @@ BasicBlockPass *llvm::createBBVectorizePass() {   return new BBVectorize();  } +bool llvm::vectorizeBasicBlock(Pass *P, BasicBlock &BB) { +  BBVectorize BBVectorizer(P); +  return BBVectorizer.vectorizeBB(BB); +} + -- 1.7.5.4 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-a-the-function-vectorizeBasicBlock-which-allow-u.patch Type: text/x-diff Size: 3525 bytes Desc: not available URL: <http://lists.llvm.org/piper...

...ysisUsage(AnalysisUsage &AU) const { >       BasicBlockPass::getAnalysisUsage(AU); > @@ -1861,3 +1871,8 @@ BasicBlockPass *llvm::createBBVectorizePass() { >   return new BBVectorize(); >  } > > +bool llvm::vectorizeBasicBlock(Pass *P, BasicBlock &BB) { > +  BBVectorize BBVectorizer(P); > +  return BBVectorizer.vectorizeBB(BB); > +} > + > -- > 1.7.5.4 -- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory

Chris, I'd like to take code ownership of the BBVectorize code. Although not quite directory granularity (because the loop vectorizer is also in that directory), it is self-contained. Thanks again, Hal -- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory

If you don't use BBVectorize at all, you can ignore this. Hal suggested this in a thread in 2014: http://lists.llvm.org/pipermail/llvm-dev/2014-November/079091.html None objected then, and I don't think any new uses have arisen so I plan to just remove it. It is causing maintenance burden, complexity, and is a set of features I'd rather not port to the new PM. Just an FYI email to

Hello, After investigating PR14133, I've discovered that jump threading can output self-referential instructions: %inc.us = add nsw i32 %inc.us, 1 At least in the test case for that bug report, the relevant code is later deleted (perhaps it is unreachable), and so this does not cause a problem. Unfortunately, when vectorization is enabled, this instruction causes BBVectorize to hang. Should

FWIW, I don't think we need any process for folks to be an owner of a file (or collection of files) for which they are the primary author of all of the code... On Tue, Nov 13, 2012 at 2:19 PM, Hal Finkel <hfinkel at anl.gov> wrote: > Chris, > > I'd like to take code ownership of the BBVectorize code. Although not quite directory granularity (because the loop vectorizer is

> > Okay. If you'll update your local BBVectorize patches, then we can pull them upstream. Then we'll just need to update the unroller. If I understand this thread correctly, you want to enable vecorization by telling the BB vectorizer that different operations are independent. I understand your motivation and I agree that this is indeed one way to do vectorization. However, I

...r should already vectorize the > > loop. > > Yes, the loop vectorizer should be a better match for the parallel > (inner)loops. > > That's why I've been pushing the parallel loop metadata: to go > towards > using the generic loop vectorizer instead of the hacked bbvectorizer > for > work-group autovectorization in pocl. Unfortunately, it needs some > more work > still to be efficient for this purpose (like discussed), but a step > towards it > has been now made and it can vectorize some work-group functions with > pocl. > That's good. >...

...roject), so I >> cannot make any >> promises on when I might find time to work on it again. So, if you >> want to >> see the parallel loop iteration MD happen sooner, I'd recommend you >> dig into >> it. I think we'd like to start from the scratch for the bbvectorizer >> utilization >> in pocl anyways, that is, would add the metadata support first and >> then use it >> in a fresh bbvectorizer version. The current hacked version in pocl >> seems not >> to be upstreamable easily as it has lagged behind some LLVM versions >&gt...

...are > independent, then the loop vectorizer should already vectorize the loop. Yes, the loop vectorizer should be a better match for the parallel (inner)loops. That's why I've been pushing the parallel loop metadata: to go towards using the generic loop vectorizer instead of the hacked bbvectorizer for work-group autovectorization in pocl. Unfortunately, it needs some more work still to be efficient for this purpose (like discussed), but a step towards it has been now made and it can vectorize some work-group functions with pocl. That's good. BTW, there's at least one thing the bbvec...

...promises on when I might find time to work on it again. So, if you > >> want to > >> see the parallel loop iteration MD happen sooner, I'd recommend > >> you > >> dig into > >> it. I think we'd like to start from the scratch for the > >> bbvectorizer > >> utilization > >> in pocl anyways, that is, would add the metadata support first and > >> then use it > >> in a fresh bbvectorizer version. The current hacked version in > >> pocl > >> seems not > >> to be upstreamable easily as it...

Owen Anderson and I would like to be the co-owners of SelectionDAG. On Nov 13, 2012, at 2:29 PM, Chandler Carruth <chandlerc at google.com> wrote: > FWIW, I don't think we need any process for folks to be an owner of a > file (or collection of files) for which they are the primary author of > all of the code... > > On Tue, Nov 13, 2012 at 2:19 PM, Hal Finkel

...t exploits the independent iterations (WIs) information along with the other OpenCL AA helping features (disjoint address spaces). We use this AA down to the custom instruction scheduler of ours with the TCE target to help the VLIW-style scheduling/bundling of multiple WIs. I have hoped to get the BBVectorizer and the "unrolled parallel loop AA" functionality upstreamed as it applies to all fully parallel loops, not just the OpenCL "work-item loops", and I hate to have the forked BBVectorizer in pocl. The metadata scheme should be thought through, however, to make it cleaner than our...

On Nov 13, 2012, at 2:41 PM, Nadav Rotem <nrotem at apple.com> wrote: > Owen Anderson and I would like to be the co-owners of SelectionDAG. I'm not a big fan of co-owners: how will you know which pieces you each are covering? Dan Gohman would be another candidate for owner of this area. Can we have only one owner? -Chris > > > On Nov 13, 2012, at 2:29 PM, Chandler

----- Original Message ----- > From: "Andrew Trick" <atrick at apple.com> > To: "Tobias Grosser" <tobias at grosser.es> > Cc: "llvmdev at cs.uiuc.edu Dev" <llvmdev at cs.uiuc.edu> > Sent: Sunday, February 17, 2013 2:32:25 PM > Subject: Re: [LLVMdev] Parallel Loop Metadata > > > > > > On Feb 11, 2013, at 2:58 PM,

On Feb 17, 2013, at 1:15 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> Unrolling OTOH should be aware of and preserve any loop metadata. > > If the unroller somehow differentiates the metadata coming from different loop iterations, then BBVectorize can use this information as well. Even better, we could make BasicAA understand that appropriately marked loads and stores from

On Nov 13, 2012, at 11:43 PM, Evan Cheng <evan.cheng at apple.com> wrote: > SelectionDAG is big enough to have multiple owners. Legalizer, dag combine, etc. can each have a separate owner. I don't think that makes sense given our model of code owner. The important task here is ensuring that each piece gets reviewed. Splitting things up at such a fine level doesn't help with

SelectionDAG is big enough to have multiple owners. Legalizer, dag combine, etc. can each have a separate owner. Evan On Nov 13, 2012, at 5:56 PM, Chris Lattner <clattner at apple.com> wrote: > On Nov 13, 2012, at 2:41 PM, Nadav Rotem <nrotem at apple.com> wrote: >> Owen Anderson and I would like to be the co-owners of SelectionDAG. > > I'm not a big fan of

...>> >> Updating BB vectorizer to use work item metadata was rather trivial >> addition of a test for difference in identifiers, very similar to >> one in AA (though we also record position of the instruction in the >> originating block) and should be trivial to add to BBvectorizer as >> well, using parallel metadata. >> It become major mess once complains started about speed, e.g. pocl >> version does not have any search limits or maximum instr per group >> etc, so finding all candidate pairs become rather time consuming. >> So the candidate sel...