search for: bbvectorization

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

Hi Hal, I add a function named "vectorizeBasicBlock" which allow users to perform basic block vectoirzation inside their pass. But i am not sure whether i missed something as no one use the function right now (But it will be used by Polly sometimes later[1]). In addition, we (tobi and me) also want to make the vectorizer being configured command line flags. To achieve this, we are

Ether, Sounds great! Please keep in mind that, eventually, we'll also want to configure those options from TLI (or something similar). The patch looks good to me. -Hal On Wed, 4 Apr 2012 23:54:18 +0800 Hongbin Zheng <etherzhhb at gmail.com> wrote: > Hi Hal, > > I add a function named "vectorizeBasicBlock" which allow users to > perform basic block

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

----- Original Message ----- > From: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi> > To: "Nadav Rotem" <nrotem at apple.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "Tobias Grosser" <tobias at grosser.es>, "llvmdev at cs.uiuc.edu Dev" > <llvmdev at cs.uiuc.edu> > Sent: Tuesday, February 19, 2013

...originating code), which may not be case in general BB vectorized cases. Anyways, if the loop metadata gets updated, I can have a look at updating AA and moving it from pocl to LLVM, but not likely this week (maybe Pekka can provide it sooner if there is a rush). I can not make any promises about BBVectorization atm, unfortunately. regards Vlado > > Thanks again, > Hal > >> >> BR, >> -- >> --Pekka >> >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu...

Hi, On 02/19/2013 02:31 AM, Nadav Rotem wrote: > vectorization. However, I don't completely understand something. If we > already have the information that consecutive iterations of the loops 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

...es that you've implemented in your version? > > Anyways, if the loop metadata gets updated, I can have a look at > updating AA and moving it from pocl to LLVM, but not likely this > week (maybe Pekka can provide it sooner if there is a rush). > I can not make any promises about BBVectorization atm, unfortunately. Great, thanks! -Hal > > regards > Vlado > > > > Thanks again, > > Hal > > > >> > >> BR, > >> -- > >> --Pekka > >> > >> > > > > __________________________________________...

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

On 02/17/2013 11:15 PM, Hal Finkel wrote: > 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 different iterations don't alias. Then the AA-based > dependency breaker in the scheduler could

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

...cture). regards Vlado > >> >> Anyways, if the loop metadata gets updated, I can have a look at >> updating AA and moving it from pocl to LLVM, but not likely this >> week (maybe Pekka can provide it sooner if there is a rush). >> I can not make any promises about BBVectorization atm, unfortunately. > > Great, thanks! > > -Hal > >> >> regards >> Vlado >>> >>> Thanks again, >>> Hal >>> >>>> >>>> BR, >>>> -- >>>> --Pekka >>>> >>>&gt...