diff mbox series

[3/4] ranger: Revert the workaround introduced in PR112788 [PR112993]

Message ID 79b24bb3-f5b7-5ada-ca84-a1deda04df83@linux.ibm.com
State New
Headers
Series [1/4] rs6000: Make all 128 bit scalar FP modes have 128 bit precision [PR112993] |

Commit Message

Kewen.Lin May 8, 2024, 5:32 a.m. UTC 
  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

Comments

Aldy Hernandez May 8, 2024, 2:06 p.m. UTC | #1 
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 mbox series

Patch

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