On 11/21/2017 09:45 AM, Richard Sandiford wrote: > Richard Biener <richard.guent...@gmail.com> writes: >> 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. > > 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.
Jeff
