[gcc r14-6478] range: Workaround different type precision between _Float128 and long double [PR112788]

[Kewen Lin]

https://gcc.gnu.org/g:fda8e2f8292a90dac9fcaf952bad6fff3aa7fff2

commit r14-6478-gfda8e2f8292a90dac9fcaf952bad6fff3aa7fff2
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Tue Dec 12 20:39:34 2023 -0600

    range: Workaround different type precision between _Float128 and long double [PR112788]
    
    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.
    
    [1] https://inbox.sourceware.org/gcc-patches/718677e7-614d-7977-312d-05a75e1fd5b4@linux.ibm.com/
    
            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.

Diff:
---
 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