[llvm-dev] Enabling scalarized conditional stores in the loop vectorizer

Tue Dec 13 15:42:56 PST 2016

Performance looks more or less flat for me.

Michael

On Tue, Dec 13, 2016 at 8:15 AM, Hal Finkel via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> ----- Original Message -----
> > From: "Arnold Schwaighofer via llvm-dev" <llvm-dev at lists.llvm.org>
> > To: "Matthew Simpson" <mssimpso at codeaurora.org>
> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>
> > Sent: Tuesday, December 13, 2016 9:17:08 AM
> > Subject: Re: [llvm-dev] Enabling scalarized conditional stores in the
> loop vectorizer
> >
> > I added this feature for libquantum
> > (http://llvm.org/viewvc/llvm-project?view=revision&revision=200270)
> > waiting for an update to the cost model modeling the scalarization
> > of stores which you recently added.
> >
> > Assuming no serious regressions this SGTM.
>
> Great!
>
>  -Hal
>
> >
> >
> > > On Dec 13, 2016, at 5:41 AM, Matthew Simpson
> > > <mssimpso at codeaurora.org> wrote:
> > >
> > > Hi Michael,
> > >
> > > Thanks for testing this on your benchmarks and target. I think the
> > > results will help guide the direction we go. I tested the feature
> > > with spec2k/2k6 on AArch64/Kryo and saw minor performance swings,
> > > aside from a large (30%) improvement in spec2k6/libquantum. The
> > > primary loop in that benchmark has a conditional store, so I
> > > expected it to benefit.
> > >
> > > Regarding the cost model, I think the vectorizer's modeling of the
> > > conditional stores is good. We could potentially improve it by
> > > using profile information if available. But I'm not sure of the
> > > quality of the individual TTI implementations other than AArch64.
> > > I assume they are adequate.
> > >
> > > Since the conditional stores remain scalar in the vector loop,
> > > their cost is essentially the same as it is in the scalar loop
> > > (aside from scalarization overhead, which we account for). So when
> > > we compare the cost of the scalar and vector loops when deciding
> > > to vectorize, we're basically comparing the cost of everything
> > > else.
> > >
> > > -- Matt
> > >
> > > On Mon, Dec 12, 2016 at 7:03 PM, Michael Kuperstein via llvm-dev
> > > <llvm-dev at lists.llvm.org> wrote:
> > > Conceptually speaking, I think we really ought to enable this.
> > >
> > > Practically, I'm going to test it on our benchmarks (on x86), and
> > > see if we have any regressions - this seems like a fairly major
> > > change.
> > > Re targets - let's see where we stand w.r.t regressions first. What
> > > kind of performance testing have you already run on this? Do you
> > > know of specific targets where the cost model is known to be good
> > > enough, so it's clearly beneficial?
> > >
> > > (+Arnold, who probably knows why this is disabled by default. :-) )
> > >
> > > Thanks,
> > >   Michael
> > >
> > > On Mon, Dec 12, 2016 at 2:52 PM, Matthew Simpson
> > > <mssimpso at codeaurora.org> wrote:
> > > Hi,
> > >
> > > I'd like to enable the scalarized conditional stores feature in the
> > > loop vectorizer (-enable-cond-stores-vec=true). The feature allows
> > > us to vectorize loops containing conditional stores that must be
> > > scalarized and predicated in the vectorized loop.
> > >
> > > Note that this flag does not affect the decision to generate masked
> > > vector stores. That is a separate feature and is guarded by a TTI
> > > hook. Currently, we give up on loops containing conditional stores
> > > that must be scalarized (i.e., conditional stores that can't be
> > > represented with masked vector stores). If the feature is enabled,
> > > we attempt to vectorize those loops if profitable, while
> > > scalarizing and predicating the conditional stores.
> > >
> > > I think these stores are fairly well modeled in the cost model at
> > > this point using the static estimates. They're modeled similar to
> > > the way we model other non-store conditional instructions that
> > > must be scalarized and predicated (e.g., instructions that may
> > > divide by zero); however, only the conditional stores are
> > > currently disabled by default.
> > >
> > > I'd appreciate any opinions on how/if we can enable this feature.
> > > For example, can we enable it for all targets or would a
> > > target-by-target opt-in mechanism using a TTI hook be preferable?
> > > If you'd like to test the feature on your target, please report
> > > any significant regressions and improvements you find.
> > >
> > > Thanks!
> > >
> > > -- Matt
> > >
> > >
> > > _______________________________________________
> > > LLVM Developers mailing list
> > > llvm-dev at lists.llvm.org
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> > >
> > >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
>
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161213/c6345477/attachment.html>