| Message ID | 79b24bb3-f5b7-5ada-ca84-a1deda04df83@linux.ibm.com |
|---|---|
| State | New |
| Headers | show |
| Series | [1/4] rs6000: Make all 128 bit scalar FP modes have 128 bit precision [PR112993] | expand |
I'll defer to the PPC maintainers, but LGTM. The less special casing, the better. Aldy On Wed, May 8, 2024, 07:33 Kewen.Lin <linkw@linux.ibm.com> wrote: > Hi, > > This reverts commit r14-6478-gfda8e2f8292a90 "range: > Workaround different type precision between _Float128 and > long double [PR112788]" as the fixes for PR112993 make > all 128 bits scalar floating point have the same 128 bit > precision, this workaround isn't needed any more. > > Bootstrapped and regress-tested on: > - powerpc64-linux-gnu P8/P9 (with ibm128 by default) > - powerpc64le-linux-gnu P9/P10 (with ibm128 by default) > - powerpc64le-linux-gnu P9 (with ieee128 by default) > > Is it OK for trunk if {1,2}/4 in this series get landed? > > BR, > Kewen > ----- > > PR target/112993 > > gcc/ChangeLog: > > * value-range.h (range_compatible_p): Remove the workaround on > different type precision between _Float128 and long double. > --- > gcc/value-range.h | 10 ++-------- > 1 file changed, 2 insertions(+), 8 deletions(-) > > diff --git a/gcc/value-range.h b/gcc/value-range.h > index 9531df56988..39de7daf3d9 100644 > --- a/gcc/value-range.h > +++ b/gcc/value-range.h > @@ -1558,13 +1558,7 @@ range_compatible_p (tree type1, tree type2) > // types_compatible_p requires conversion in both directions to be > useless. > // GIMPLE only requires a cast one way in order to be compatible. > // Ranges really only need the sign and precision to be the same. > - return TYPE_SIGN (type1) == TYPE_SIGN (type2) > - && (TYPE_PRECISION (type1) == TYPE_PRECISION (type2) > - // FIXME: As PR112788 shows, for now on rs6000 _Float128 has > - // type precision 128 while long double has type precision 127 > - // but both have the same mode so their precision is actually > - // the same, workaround it temporarily. > - || (SCALAR_FLOAT_TYPE_P (type1) > - && TYPE_MODE (type1) == TYPE_MODE (type2))); > + return (TYPE_PRECISION (type1) == TYPE_PRECISION (type2) > + && TYPE_SIGN (type1) == TYPE_SIGN (type2)); > } > #endif // GCC_VALUE_RANGE_H > -- > 2.39.1 > >
diff --git a/gcc/value-range.h b/gcc/value-range.h index 9531df56988..39de7daf3d9 100644 --- a/gcc/value-range.h +++ b/gcc/value-range.h @@ -1558,13 +1558,7 @@ range_compatible_p (tree type1, tree type2) // types_compatible_p requires conversion in both directions to be useless. // GIMPLE only requires a cast one way in order to be compatible. // Ranges really only need the sign and precision to be the same. - return TYPE_SIGN (type1) == TYPE_SIGN (type2) - && (TYPE_PRECISION (type1) == TYPE_PRECISION (type2) - // FIXME: As PR112788 shows, for now on rs6000 _Float128 has - // type precision 128 while long double has type precision 127 - // but both have the same mode so their precision is actually - // the same, workaround it temporarily. - || (SCALAR_FLOAT_TYPE_P (type1) - && TYPE_MODE (type1) == TYPE_MODE (type2))); + return (TYPE_PRECISION (type1) == TYPE_PRECISION (type2) + && TYPE_SIGN (type1) == TYPE_SIGN (type2)); } #endif // GCC_VALUE_RANGE_H
Hi, This reverts commit r14-6478-gfda8e2f8292a90 "range: Workaround different type precision between _Float128 and long double [PR112788]" as the fixes for PR112993 make all 128 bits scalar floating point have the same 128 bit precision, this workaround isn't needed any more. Bootstrapped and regress-tested on: - powerpc64-linux-gnu P8/P9 (with ibm128 by default) - powerpc64le-linux-gnu P9/P10 (with ibm128 by default) - powerpc64le-linux-gnu P9 (with ieee128 by default) Is it OK for trunk if {1,2}/4 in this series get landed? BR, Kewen ----- PR target/112993 gcc/ChangeLog: * value-range.h (range_compatible_p): Remove the workaround on different type precision between _Float128 and long double. --- gcc/value-range.h | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) -- 2.39.1