Re: PING^1 [PATCH] range: Workaround different type precision issue between _Float128 and long double [PR112788]
Hi Jakub & Andrew, on 2023/12/12 22:42, Jakub Jelinek wrote: > On Tue, Dec 12, 2023 at 09:33:38AM -0500, Andrew MacLeod wrote: >> I leave this for the release managers, but I am not opposed to it for this >> release... It would be nice to remove it for the next release > > I can live with it for GCC 14, so ok, but it is very ugly. Thanks, pushed as r14-6478-gfda8e2f8292a90. And yes, I strongly agree that we should get rid of this in next release. > > We should fix it in a better way for GCC 15+. > I think we shouldn't lie, both on the mode precisions and on type > precisions. The middle-end already contains some hacks to make it > work to some extent on 2 different modes with same precision (for BFmode vs. > HFmode), on the FE side if we need a target hook the C/C++ FE will use > to choose type ranks and/or the type for binary operations, so be it. > It would be also great if rs6000 backend had just 2 modes for 128-bit > floats, one for IBM double double, one for IEEE quad, not 3 as it has now, > perhaps with TFmode being a macro that conditionally expands to one or the > other. Or do some tweaks in target hooks to keep backwards compatibility > with mode attribute and similar. Thanks for all the insightful suggestions, I just filed PR112993 for further tracking and self-assigned it. BR, Kewen
Re: PING^1 [PATCH] range: Workaround different type precision issue between _Float128 and long double [PR112788]
On Tue, Dec 12, 2023 at 09:33:38AM -0500, Andrew MacLeod wrote: > I leave this for the release managers, but I am not opposed to it for this > release... It would be nice to remove it for the next release I can live with it for GCC 14, so ok, but it is very ugly. We should fix it in a better way for GCC 15+. I think we shouldn't lie, both on the mode precisions and on type precisions. The middle-end already contains some hacks to make it work to some extent on 2 different modes with same precision (for BFmode vs. HFmode), on the FE side if we need a target hook the C/C++ FE will use to choose type ranks and/or the type for binary operations, so be it. It would be also great if rs6000 backend had just 2 modes for 128-bit floats, one for IBM double double, one for IEEE quad, not 3 as it has now, perhaps with TFmode being a macro that conditionally expands to one or the other. Or do some tweaks in target hooks to keep backwards compatibility with mode attribute and similar. Jakub
Re: PING^1 [PATCH] range: Workaround different type precision issue between _Float128 and long double [PR112788]
I leave this for the release managers, but I am not opposed to it for this release... It would be nice to remove it for the next release Andrew On 12/12/23 01:07, Kewen.Lin wrote: Hi, Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639140.html BR, Kewen on 2023/12/4 17:49, Kewen.Lin wrote: Hi, As PR112788 shows, on rs6000 with -mabi=ieeelongdouble type _Float128 has the different type precision (128) from that (127) of type long double, but actually they has the same underlying mode, so they have the same precision as the mode indicates the same real type format ieee_quad_format. It's not sensible to have such two types which have the same mode but different type precisions, some fix attempt was posted at [1]. As the discussion there, there are some historical reasons and practical issues. Considering we passed stage 1 and it also affected the build as reported, this patch is trying to temporarily workaround it. I thought to introduce a hookpod but that seems a bit overkill, assuming scalar float type with the same mode should have the same precision looks sensible. Bootstrapped and regtested on powerpc64-linux-gnu P7/P8/P9 and powerpc64le-linux-gnu P9/P10. Is it ok for trunk? [1] https://inbox.sourceware.org/gcc-patches/718677e7-614d-7977-312d-05a75e1fd...@linux.ibm.com/ BR, Kewen PR tree-optimization/112788 gcc/ChangeLog: * value-range.h (range_compatible_p): Workaround same type mode but different type precision issue for rs6000 scalar float types _Float128 and long double. --- gcc/value-range.h | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/gcc/value-range.h b/gcc/value-range.h index 33f204a7171..d0a84754a10 100644 --- a/gcc/value-range.h +++ b/gcc/value-range.h @@ -1558,7 +1558,13 @@ 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_PRECISION (type1) == TYPE_PRECISION (type2) - && TYPE_SIGN (type1) == TYPE_SIGN (type2)); + 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))); } #endif // GCC_VALUE_RANGE_H -- 2.42.0
