search for: bbvectorize

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

...ch the pass so that it do not read the options like ReqChainDepth, SearchLimit, SplatBreaksChain, ... etc. from the command line option directly, but read from an instance of the VectorizeConfig class, where the VectorizeConfig class is designed to provide the vectorize related parameters to to the BBVectorize pas. After this, people can pass target specific vectorize configuration to the BBVectorize pass in tools like LLC. And original createBBVectorizePass function can create a VectorizeConfig that read the configuration from the commandline options and pass it to the BBVectorizePass, hence users can...

...it do not read the options like ReqChainDepth, > SearchLimit, SplatBreaksChain, ... etc. from the command line option > directly, but read from an instance of the VectorizeConfig class, > where the VectorizeConfig class is designed to provide the vectorize > related parameters to to the BBVectorize pas. > > After this, people can pass target specific vectorize configuration to > the BBVectorize pass in tools like LLC. And original > createBBVectorizePass function can create a VectorizeConfig that read > the configuration from the commandline options and pass it to the > BBV...

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

...ding 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 I make BBVectorize ignore this kind of thing, on the assumption that it occurs only in unreachable (or otherwise dead) code, or should this be fixed at the source (in jump threading in this case)? Thanks again, Hal -- Hal Finkel Postdoctoral Appointee Leadership Computing Facilit...

...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 also in that directory), it is self-contained. > > Thanks again, > Hal > > -- > Hal Finkel > Postdoctoral Appointee > Leadership Computing Facility > Argonne National Laboratory > __________...

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

...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 >&g...

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

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

...ss 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 also in that directory), it is self-contained. >> >> Thanks again, >> Hal >> >> -- >> Hal Finkel >> Postdoctoral Appointee >> Leadership Computing Facility >> Argon...

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 also make use of the information. > Thoughts? This is...

...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 also in that directory), it is self-contained. >>> >>> Thanks again, >>> Hal >>> >>> -- >>> Hal Finkel >>> Postdoctoral Appointee >>> Leadership C...

...loop.exit: ; preds = %loop.i > ret void > } > > > !0 = metadata !{metadata !"loop"} > > > --- > 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 different iterations don't alias. Then the AA-based dependency breaker in the scheduler could also make use of the information. Thoughts? -Hal > > > -And...

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 different iterations don't alias. Then the AA-based dependency breaker in the scheduler could also make use of the information. Thoughts? That could work. Eventually...

...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 also in that directory), it is self-contained. >>>>> >>>>> Thanks again, >>>>> Hal >>>>> >>>>> -- >>>>> Hal Finkel >>>&...

...ollection 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 also in that directory), it is self-contained. >>>> >>>> Thanks again, >>>> Hal >>>> >>>> -- >>>> Hal Finkel >>>> Postdoctoral Appoint...

>>> >>> - 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 implementation of AA uses work item metadata as well as >> 'region' metadata identifiers (regions begin separated by barriers). >> So in order to provide similar functionality, parallel loop m...