On 2/21/2022 3:55 AM, Richard Biener via Gcc-patches wrote:
On Mon, Feb 21, 2022 at 9:31 AM Roger Sayle <ro...@nextmovesoftware.com> wrote:
Hi Marc,
I'm assuming that the use (semantics) of a REDUC_PLUS expr allow the
reduction to be done in any order, for example the testcase requires
-ffast-math to allow the REDUC_PLUS to be introduced in the first place.
This also applies explains why the patch doesn't need to distinguish
negative zeros from positive zeros in ctor_single_nonzero_element
(but it's perhaps something to beware of in uses of VECTOR_CST's
single_nonzero_element).
.IFN_REDUC_PLUS directly maps to the reduc_plus_scal optab
which does not specify an operation order. There's also
fold_left_plus which does (left-to-right).
fold-left-plus is meant to be a strictly in-order reduction, which
implies (at least to me) that REDUC_PLUS allows reassociation.
An argument could be made that constant folding should do what
the CPU will end up doing but we're already not doing that for
double arithmetic and flush-to-zero enabled with -ffast-math and
denormals I think.
Right. We can also lose inexact state when folding, but I think that's
largely considered OK as well.
jeff
