Add support for in-order addition reduction using SVE FADDA

Richard Sandiford richard.sandiford@linaro.org
Tue Nov 21 17:13:00 GMT 2017


Jeff Law <law@redhat.com> writes:
> On 11/21/2017 09:45 AM, Richard Sandiford wrote:
>> Richard Biener <richard.guenther@gmail.com> writes:
>>> 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.
>> 
>> OK, here's 2/3.  It just splits out some code for reuse in 3/3.
> [ ... ]
> Is this going to obsolete any of the stuff posted to date?  I'm thinking
> specifically about "Add support for bitwise reductions", but perhaps
> there are others.

It means that those codes go in and then come out again, yeah, although
the end result is the same.

OK, I'll redo it so that this goes first and then repost a new bitwise
patch too.

Thanks,
Richard



More information about the Gcc-patches mailing list