[PATCH] D14116: [SLP] Be more aggressive about reduction width selection.

[Charlie Turner via llvm-commits]

chatur01 created this revision.
chatur01 added reviewers: nadav, jmolloy.
chatur01 added a subscriber: llvm-commits.
chatur01 set the repository for this revision to rL LLVM.
Herald added a subscriber: aemerson.

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!

Repository:
  rL LLVM

http://reviews.llvm.org/D14116

Files:
  lib/Transforms/Vectorize/SLPVectorizer.cpp
  test/Transforms/SLPVectorizer/AArch64/horizontal.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D14116.38531.patch
Type: text/x-patch
Size: 9230 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151027/70d53f5b/attachment.bin>