On Mon, Nov 20, 2017 at 1:54 PM, Richard Sandiford <richard.sandif...@linaro.org> wrote: > Richard Biener <richard.guent...@gmail.com> writes: >> On Fri, Nov 17, 2017 at 5:53 PM, Richard Sandiford >> <richard.sandif...@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
