Page MenuHomePhabricator

[SLP] Be more aggressive about reduction width selection.
ClosedPublic

Authored by chatur01 on Oct 27 2015, 6:52 AM.

Details

Summary

This change could be way off-piste, I'm looking for any feedback on whether it's an acceptable approach.

It never seems to be a problem to gobble up as many reduction values as can be found, and then to attempt to reduce the resulting tree. Some of the workloads I'm looking at have been aggressively unrolled by hand, and by selecting reduction widths that are not constrained by a vector register size, it becomes possible to profitably vectorize. My test case shows such an unrolling which SLP was not vectorizing (on neither ARM nor X86) before this patch, but with it does vectorize.

I measure no significant compile time impact of this change when combined with D13949 and D14063. There are also no significant performance regressions on ARM/AArch64 in SPEC or LNT.

The more principled approach I thought of was to generate several candidate tree's and use the cost model to pick the cheapest one. That seemed like quite a big design change (the algorithms seem very much one-shot), and would likely be a costly thing for compile time. This seemed to do the job at very little cost, but I'm worried I've misunderstood something!

Diff Detail

Repository
rL LLVM

Event Timeline

chatur01 retitled this revision from to [SLP] Be more aggressive about reduction width selection..
chatur01 updated this object.
chatur01 added reviewers: nadav, jmolloy.
chatur01 set the repository for this revision to rL LLVM.
chatur01 added a subscriber: llvm-commits.
This revision was automatically updated to reflect the committed changes.