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

[Nadav Rotem via llvm-commits]

> On Oct 27, 2015, at 6:52 AM, Charlie Turner <charlie.turner at arm.com> wrote:
> 
> 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!


LGTM. 

The problem with using the cost model to evaluate multiple combinations of the vector-trees is that it can be expensive in terms of compile time. I think that the solution that you propose makes sense. LGTM. Please commit. 


> 
> Repository:
>  rL LLVM
> 
> http://reviews.llvm.org/D14116
> 
> Files:
>  lib/Transforms/Vectorize/SLPVectorizer.cpp
>  test/Transforms/SLPVectorizer/AArch64/horizontal.ll
> 
> <D14116.38531.patch>