Re: [PATCH] gimple-fold: Don't optimize wierdo floating point value reads [PR95450]

[Jeff Law <law@redhat.com>]

On Mon, 2020-08-24 at 12:51 +0200, Richard Biener wrote:
> On Wed, 12 Aug 2020, Jakub Jelinek wrote:
> 
> > On Wed, Aug 12, 2020 at 04:30:35PM +0200, Richard Biener wrote:
> > > Not a final review but if we care for this kind of normalization at all
> > > the we should do so consistently, thus for both encode and interpret and
> > > for all modes.  For FP we could also check if we'd consider the values
> > > equal rather than whether we would en/decode them to the same bit pattern
> > > (which might or might not be what an actual ISA gpr<->fpr reg move would
> > > do)
> > 
> > I think the verification that what we encode can be interpreted back
> > woiuld be only an internal consistency check (so perhaps for ENABLE_CHECKING
> > if flag_checking only, but if both directions perform it, then we need
> > to avoid mutual recursion).
> > While for the other direction (interpretation), at least for the broken by
> > design long doubles we just know we can't represent in GCC all valid values.
> > The other floating point formats are just theoretical case, perhaps we would
> > canonicalize something to a value that wouldn't trigger invalid exception
> > when without canonicalization it would trigger it at runtime, so let's just
> > ignore those.
> > 
> > Adjusted (so far untested) patch to do it in native_interpret_real instead
> > and limit it to the MODE_COMPOSITE_P cases, for which e.g.
> > fold-const.c/simplify-rtx.c punts in several other places too because we just
> > know we can't represent everything.
> > 
> > E.g.
> >       /* Don't constant fold this floating point operation if the
> >          result may dependent upon the run-time rounding mode and
> >          flag_rounding_math is set, or if GCC's software emulation
> >          is unable to accurately represent the result.  */
> >       if ((flag_rounding_math
> >            || (MODE_COMPOSITE_P (mode) && !flag_unsafe_math_optimizations))
> >           && (inexact || !real_identical (&result, &value)))
> >         return NULL_TREE;
> > Or perhaps guard it with MODE_COMPOSITE_P (mode) && !flag_unsafe_math_optimizations
> > too, thus break what gnulib / m4 does with -ffast-math, but not normally?
> 
> OK.
> 
> Richard.
> 
> > 2020-08-12  Jakub Jelinek  <jakub@redhat.com>
> > 
> > 	PR target/95450
> > 	* fold-const.c (native_interpret_real): For MODE_COMPOSITE_P modes
> > 	punt if the to be returned REAL_CST does not encode to the bitwise
> > 	same representation.
Jakub, can you pull this into F33/F34.  It's affecting a few packages (assuming
this is meant to fix the gnulib FP testsuite failures on ppc64le).

Jeff