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

[Hal Finkel via llvm-dev]

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