This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

> 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 can give it a go anyway if you think it's worth it.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]