Re: Add support for in-order addition reduction using SVE FADDA

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

On Mon, Nov 20, 2017 at 1:54 PM, Richard Sandiford
<richard.sandiford@linaro.org> wrote:
> Richard Biener <richard.guenther@gmail.com> writes:
>> On Fri, Nov 17, 2017 at 5:53 PM, Richard Sandiford
>> <richard.sandiford@linaro.org> wrote:
>>> This patch adds support for in-order floating-point addition reductions,
>>> which are suitable even in strict IEEE mode.
>>>
>>> Previously vect_is_simple_reduction would reject any cases that forbid
>>> reassociation.  The idea is instead to tentatively accept them as
>>> "FOLD_LEFT_REDUCTIONs" and only fail later if there is no target
>>> support for them.  Although this patch only handles the particular
>>> case of plus and minus on floating-point types, there's no reason in
>>> principle why targets couldn't handle other cases.
>>>
>>> The vect_force_simple_reduction change makes it simpler for parloops
>>> to read the type of reduction.
>>>
>>> Tested on aarch64-linux-gnu (with and without SVE), x86_64-linux-gnu
>>> and powerpc64le-linux-gnu.  OK to install?
>>
>> I don't like that you add a new tree code for this.  A new IFN looks more
>> suitable to me.
>
> OK.

Thanks.  I'd like to eventually get rid of other vectorizer tree codes as well,
like the REDUC_*_EXPR, DOT_PROD_EXPR and SAD_EXPR.  IFNs
are now really the way to go for "target instructions on GIMPLE".

>> Also I think if there's a way to handle this correctly with target support
>> you can also implement a fallback if there is no such support increasing
>> test coverage.  It would basically boil down to extracting all scalars from
>> the non-reduction operand vector and performing a series of reduction
>> ops, keeping the reduction PHI scalar.  This would also support any
>> reduction operator.
>
> Yeah, but without target support, that's probably going to be expensive.
> It's a bit like how we can implement element-by-element loads and stores
> for cases that don't have target support, but had to explicitly disable
> that in many cases, since the cost model was too optimistic.

I expect that for V2DF or even V4DF it might be profitable in quite a number
of cases.  V2DF definitely.

> I can give it a go anyway if you think it's worth it.

I think it is.

Richard.

> As far as testing coverage goes: I think the SVE port is just going
> to have to take the hit of being the only port that uses this stuff
> for now.  The AArch64 testsuite patches test SVE assembly generation
> for non-SVE targets, so it does get at least some coverge on normal
> AArch64 test runs.  But obviously assembly tests only go so far...
>
> Thanks,
> Richard