llvm dev - Dec 2016 - Enabling scalarized conditional stores in the loop vectorizer

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161212/faf73ae2/attachment.html>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161212/a8769eaa/attachment-0001.html>

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161213/6b2fc00c/attachment.html>