Re: RFA: vectorizer patches 2/2: reduction splitting

[Richard Biener <richard dot guenther at gmail dot com>]

On Sun, Nov 11, 2018 at 9:16 AM Joern Wolfgang Rennecke
<joern.rennecke@riscy-ip.com> wrote:
>
> It's nice to use the processors vector arithmetic to good effect, but
> it's all for naught when
> there are too many moves from/to general registers cluttering up the
> loop.  With a
> double-vector reduction variable, the standard final reduction code got
> so awkward that
> the register allocator decided that the reduction variable must live in
> general purpose
> registers, not only after the loop, but across the loop patch.
> Splitting the reduction to force the first step to be done as a vector
> operation
> seemed the obvious solution. The hook was called, but the vectorizer still
> generated the vanilla final reduction code.  It turns out that the
> reduction splitting
> was calculated, but the result not used, and the calculation started anew.
>
> The attached patch fixes this.

That looks quite fragile to me or warrants further cleanups.  Can you
push up the new_phis.length assert further and elide the loop over
the PHIs?  It looks like at the very beginning we are reducing the
PHIs to a single PHI and new_phi_result is the one to look at
(and the vector is updated, but given we replace the PHI with an
assign using new_phi_result instead of the vector would be better).

RIchard.

> bootstrapped and regression tested on x86_64-pc-linux-gnu .