similar to: [LLVMdev] [RFC] Removing BBVectorize?

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

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

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

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

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

Hi All, I'm trying to understand BB Vectorizer and gone through http://llvm.org/devmtg/2012-04-12/Slides/Hal_Finkel.pdf Wanted to know how to use bb-vectorize-debug-candidate-selection and bb-vectorize-debug-pair-selection command arguments. I tried the command with debug build clang - clang -O2 test.c -mllvm -vectorize \ -mllvm -debug-only=bb-vectorize \ -mllvm

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

Already added in the commit (I think) On Fri, Jun 30, 2017 at 3:58 PM Hans Wennborg <hans at chromium.org> wrote: > On Thu, Jun 29, 2017 at 3:42 PM, Chandler Carruth via cfe-dev > <cfe-dev at lists.llvm.org> wrote: > > If you don't use BBVectorize at all, you can ignore this. > > > > Hal suggested this in a thread in 2014: > >

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

----- Original Message ----- > From: "Vladimir Guzma" <vladimir.guzma at tut.fi> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi>, "Tobias Grosser" <tobias at grosser.es>, "llvmdev at cs.uiuc.edu Dev" > <llvmdev at cs.uiuc.edu> > Sent: Tuesday, February

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

>>> >>> - Update the language reference >>> - Update the loop vectorizer (to update the metadata when it >>> unrolls) >>> - Update the regular unroller >>> - Update the alias analysis (maybe this is sufficient for basic >>> support in BBVectorize) - is your current code close enough for >>> this? >> >> Current

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

Hi all, >> Hal, this OpenCL WG autovectorization work, unfortunately, is not my >> first >> priority task at work currently (more like a pet project), 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 >>

----- Original Message ----- > From: "Vladimir Guzma" <vladimir.guzma at tut.fi> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi>, "Tobias Grosser" <tobias at grosser.es>, "llvmdev at cs.uiuc.edu Dev" > <llvmdev at cs.uiuc.edu> > Sent: Tuesday, February

On Nov 14, 2012, at 10:59 AM, Chris Lattner <clattner at apple.com> wrote: > > 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

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

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