From 44f80a370b76fd1564e280f08d6640d0f641d487 Mon Sep 17 00:00:00 2001
From: Jakub Jelinek <jakub@redhat.com>
Date: Fri, 10 Mar 2023 12:40:23 +0100
Subject: [PATCH] range-op-float: Extend lhs by 0.5ulp rather than 1ulp if not
 -frounding-math [PR109008]

This patch, incremental to the just posted one, improves the reverse
operation ranges significantly by widening just by 0.5ulp in each
direction rather than 1ulp.  Again, REAL_VALUE_TYPE has both wider
exponent range and wider mantissa precision (160 bits) than any
supported type, this patch uses the latter property.

The patch doesn't do it if -frounding-math, because then the rounding
can be +-1ulp in each direction depending on the rounding mode which
we don't know, or for IBM double double because that type is just weird
and we can't trust in sane properties.

I've performed testing of these 2 patches on 300000 random tests as with
yesterday's patch, exact numbers are in the PR, but I see very significant
improvement in the precision of the ranges while keeping it conservatively
correct.

2023-03-10  Jakub Jelinek  <jakub@redhat.com>

	PR tree-optimization/109008
	* range-op-float.cc (float_widen_lhs_range): If not
	-frounding-math and not IBM double double format, extend lhs
	range just by 0.5ulp rather than 1ulp in each direction.
---
 gcc/range-op-float.cc | 20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc
index 58606aa46112..204b3911cc48 100644
--- a/gcc/range-op-float.cc
+++ b/gcc/range-op-float.cc
@@ -2205,8 +2205,8 @@ zero_to_inf_range (REAL_VALUE_TYPE &lb, REAL_VALUE_TYPE &ub, int signbit_known)
    [1., 1.] = op1 + [1., 1.].  op1's range is not [0., 0.], but
    [-0x1.0p-54, 0x1.0p-53] (when not -frounding-math), any value for
    which adding 1. to it results in 1. after rounding to nearest.
-   So, for op1_range/op2_range extend the lhs range by 1ulp in each
-   direction.  See PR109008 for more details.  */
+   So, for op1_range/op2_range extend the lhs range by 1ulp (or 0.5ulp)
+   in each direction.  See PR109008 for more details.  */
 
 static frange
 float_widen_lhs_range (tree type, const frange &lhs)
@@ -2230,6 +2230,14 @@ float_widen_lhs_range (tree type, const frange &lhs)
 	  lb = dconstm1;
 	  SET_REAL_EXP (&lb, FLOAT_MODE_FORMAT (TYPE_MODE (type))->emax + 1);
 	}
+      if (!flag_rounding_math && !MODE_COMPOSITE_P (TYPE_MODE (type)))
+	{
+	  /* If not -frounding-math nor IBM double double, actually widen
+	     just by 0.5ulp rather than 1ulp.  */
+	  REAL_VALUE_TYPE tem;
+	  real_arithmetic (&tem, PLUS_EXPR, &lhs.lower_bound (), &lb);
+	  real_arithmetic (&lb, RDIV_EXPR, &tem, &dconst2);
+	}
     }
   if (real_isfinite (&ub))
     {
@@ -2240,6 +2248,14 @@ float_widen_lhs_range (tree type, const frange &lhs)
 	  ub = dconst1;
 	  SET_REAL_EXP (&ub, FLOAT_MODE_FORMAT (TYPE_MODE (type))->emax + 1);
 	}
+      if (!flag_rounding_math && !MODE_COMPOSITE_P (TYPE_MODE (type)))
+	{
+	  /* If not -frounding-math nor IBM double double, actually widen
+	     just by 0.5ulp rather than 1ulp.  */
+	  REAL_VALUE_TYPE tem;
+	  real_arithmetic (&tem, PLUS_EXPR, &lhs.upper_bound (), &ub);
+	  real_arithmetic (&ub, RDIV_EXPR, &tem, &dconst2);
+	}
     }
   /* Temporarily disable -ffinite-math-only, so that frange::set doesn't
      reduce the range back to real_min_representable (type) as lower bound
-- 
GitLab