similar to: [LLVMdev] Code Ownership - BBVectorize

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

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

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

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

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

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

Hal Finkel wrote: > 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

Hi Hal, > After investigating PR14133, I've discovered that jump threading can output self-referential instructions: > %inc.us = add nsw i32 %inc.us, 1 such instructions are valid in unreachable basic blocks. > 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

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

If you run with -vectorize instead of -bb-vectorize it will schedule the cleanup passes for you. -Hal Sent from my Verizon Wireless Droid -----Original message----- From: "Carl-Philip Hänsch" <cphaensch at googlemail.com> To: Hal Finkel <hfinkel at anl.gov> Cc: llvmdev at cs.uiuc.edu Sent: Tue, Feb 14, 2012 16:10:28 GMT+00:00 Subject: Re: [LLVMdev] Vectorization: Next

On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: > Tobias, > > I've attached an updated patch. It contains a few bug fixes and many > (refactoring and coding-convention) changes inspired by your comments. > > I'm currently trying to fix the bug responsible for causing a compile > failure when compiling >

That works. Thank you. Will -vectorize become default later? 2012/2/14 Hal Finkel <hfinkel at anl.gov> > If you run with -vectorize instead of -bb-vectorize it will schedule the > cleanup passes for you. > > -Hal > > *Sent from my Verizon Wireless Droid* > > > -----Original message----- > > *From: *"Carl-Philip Hänsch" <cphaensch at

I applied the patch to the trunk version successfully, although I get an error in between: 1 out of 1 hunk FAILED -- saving rejects to file lib/Transforms/IPO/CMakeLists.txt.rej Can I ignore the error? The patch exits normally except for that error. Also, I tried to apply the patch to the LLVM 3.0 but does not work at all. Is the trunk version the only one where the patch can be applied?

Carl-Philip, The reason that this does not vectorize is that it cannot vectorize the stores; this leaves only the mul-add chains (and some chains with loads), and they only have a depth of 2 (the threshold is 6). If you give clang -mllvm -bb-vectorize-req-chain-depth=2 then it will vectorize. The reason the heuristic has such a large default value is to prevent cases where it costs more to

----- Original Message ----- > From: "Ramshankar Ramanarayanan" <Ramshankar.Ramanarayanan at amd.com> > To: "Hal Finkel" <hfinkel at anl.gov>, "Dibyendu Das" <Dibyendu.Das at amd.com> > Cc: "llvmdev at cs.uiuc.edu Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, October 5, 2012 11:00:39 AM > Subject: RE: [LLVMdev]

Hi Hal! This is great! Vector-selects are always profitable compared to scalar selects. They are even emulated using a few Xor/And/Or instructions on platforms that don't have a native 'blend' support. Vector-geps on the other hand are only useful in very specific cases. Currently we do not support Load/Store instructions with a pointer-vector operand, so you need to extract each

On 28/11/2011, at 18:52, Hal Finkel wrote: > On Mon, 2011-11-28 at 17:49 +0100, Pablo Barrio wrote: >> How can I install the patch? Any step-by-step guide? > > First, grab the trunk versions of llvm and clang. This is detailed on > http://clang.llvm.org/get_started.html > > Then you apply the patch. On a Unix-like system, this is something like: > cd llvm > patch