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).
Cheers, Roger -- > -----Original Message----- > From: Marc Glisse <marc.gli...@inria.fr> > Sent: 21 February 2022 08:21 > To: Roger Sayle <ro...@nextmovesoftware.com> > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] Implement constant-folding simplifications of reductions. > > On Mon, 21 Feb 2022, Roger Sayle wrote: > > > +/* Fold REDUC (@0 op VECTOR_CST) as REDUC (@0) op REDUC > (VECTOR_CST). > > +*/ (for reduc (IFN_REDUC_PLUS IFN_REDUC_MAX IFN_REDUC_MIN > IFN_REDUC_FMAX > > + IFN_REDUC_FMIN IFN_REDUC_AND IFN_REDUC_IOR > IFN_REDUC_XOR) > > + op (plus max min IFN_FMAX IFN_FMIN bit_and bit_ior bit_xor) > > + (simplify (reduc (op @0 VECTOR_CST@1)) > > + (op (reduc:type @0) (reduc:type @1)))) > > I wonder if we need to test flag_associative_math for the 'plus' case, or if the > presence of IFN_REDUC_PLUS is enough to justify the possible loss of precision. > > -- > Marc Glisse
