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 <ja...@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
