fold, simplify-rtx: Punt on non-representable floating point constants [PR104522]

fold, simplify-rtx: Punt on non-representable floating point constants [PR104522]

For IBM double double I've added in PR95450 and PR99648 verification that
when we at the tree/GIMPLE or RTL level interpret target bytes as a REAL_CST
or CONST_DOUBLE constant, we try to encode it back to target bytes and
verify it is the same.
This is because our real.c support isn't able to represent all valid values
of IBM double double which has variable precision.
In PR104522, it has been noted that we have similar problem with the
Intel/Motorola extended XFmode formats, our internal representation isn't
able to record pseudo denormals, pseudo infinities, pseudo NaNs and unnormal
values.
So, the following patch is an attempt to extend that verification to all
floats.
Unfortunately, it wasn't that straightforward, because the
__builtin_clear_padding code exactly for the XFmode long doubles needs to
discover what bits are padding and does that by interpreting memory of
all 1s.  That is actually a valid supported value, a qNaN with negative
sign with all mantissa bits set, but the verification includes also the
padding bits (exactly what __builtin_clear_padding wants to figure out)
and so fails the comparison check and so we ICE.
The patch fixes that case by moving that verification from
native_interpret_real to its caller, so that clear_padding_type can
call native_interpret_real and avoid that extra check.

With this, the only thing that regresses in the testsuite is
+FAIL: gcc.target/i386/auto-init-4.c scan-assembler-times long\\t-16843010 5
because it decides to use a pattern that has non-zero bits in the padding
bits of the long double, so the simplify-rtx.cc change prevents folding
a SUBREG into a constant.  We emit (the testcase is -O0 but we emit worse
code at all opt levels) something like:
        movabsq $-72340172838076674, %rax
        movabsq $-72340172838076674, %rdx
        movq    %rax, -48(%rbp)
        movq    %rdx, -40(%rbp)
        fldt    -48(%rbp)
        fstpt   -32(%rbp)
instead of
        fldt    .LC2(%rip)
        fstpt   -32(%rbp)
...
.LC2:
        .long   -16843010
        .long   -16843010
        .long   65278
        .long   0
Note, neither of those sequences actually stores the padding bits, fstpt
simply doesn't touch them.
For vars with clear_padding_real_needs_padding_p types that are allocated
to memory at expansion time, I'd say much better would be to do the stores
using integral modes rather than XFmode, so do that:
        movabsq $-72340172838076674, %rax
        movq    %rax, -32(%rbp)
        movq    %rax, -24(%rbp)
directly.  That is the only way to ensure the padding bits are initialized
(or expand __builtin_clear_padding, but then you initialize separately the
value bits and padding bits).

2022-02-15  Jakub Jelinek  <jakub@redhat.com>

	PR middle-end/104522
	* fold-const.h (native_interpret_real): Declare.
	* fold-const.cc (native_interpret_real): No longer static.  Don't
	perform MODE_COMPOSITE_P verification here.
	(native_interpret_expr) <case REAL_TYPE>: But perform it here instead
	for all modes.
	* gimple-fold.cc (clear_padding_type): Call native_interpret_real
	instead of native_interpret_expr.
	* simplify-rtx.cc (simplify_immed_subreg): Perform the native_encode_rtx
	and comparison verification for all FLOAT_MODE_P modes, not just
	MODE_COMPOSITE_P.

	* gcc.dg/pr104522.c: New test.