Re: [PATCH] -ffinite-math-only A-A

[Christian BRUEL <christian dot bruel at st dot com>]

Hello,

thank you for the quick answer.

Richard Guenther wrote:
> On 8/22/07, Christian BRUEL <christian.bruel@st.com> wrote:>
>
> > Hello,
> >
> > I believe that ieee floating point A-A can be optimized to 0 under
> > -ffinite-math-only.
...
> The patch is wrong:

ok, let give it another try, if we agree that it's ok to relax the fold 
check on A-A -> 0


> > Index: fold-const.c
> > ===================================================================
> > --- fold-const.c        (revision 127666)
> > +++ fold-const.c        (working copy)
> > @@ -10152,7 +10152,8 @@
> >       if ((! FLOAT_TYPE_P (type)
> >           || (flag_unsafe_math_optimizations
>
>
>   ^^^^
> this test is the restricting one

yes, but it is too restrictive because it doesn't let the HONOR (thus 
the finite-math-only) checks if not in -funsafe-math-optimisations.

> >               && !HONOR_NANS (TYPE_MODE (type))
> > -              && !HONOR_INFINITIES (TYPE_MODE (type))))
> > +              && !HONOR_INFINITIES (TYPE_MODE (type)))
> > +          || flag_finite_math_only)
>
>
> !HONOR_NANS && !HONOR_INFINITIES is exactly flag_finite_math_only.

yes

> See also http://gcc.gnu.org/wiki/GeertBosch for some good overview on this
> matters.  So the correct fix would be to remove the
> flag_unsafe_math_optimizations

It all depends if we prefer to let the optimisation A-A->0 go only under 
a), b) or c) with :

a) unsafe-math-optimisations AND finite-math-only : current situation
b) unsafe-math-optimisations OR  finite-math-only : my proposed patch
c) finite-math-only only                          : attached patch

a) is too restrictive to my opinion. c) should be safe enough. I don't 
think b) is needed but I'm not sure.

> check instead.  (And check what IEEE says to -Inf - -Inf and Inf -
> Inf, just in case

-Inf - -Inf is Nan, Inf - -Inf would be Inf and Inf - Inf is NaN.
This A-A optimisation would give 0.0 so the !HONOR_INFINITY is required 
in all the cases.

> Geert is right with that only !HONOR_NANS is required).
!NONOR_INFINITY was already checked, I didn't add it. So maybe it was 
missing in its wiki ? CCing him.


> Richard.

Best Regards,

Christian

Index: fold-const.c
===================================================================
--- fold-const.c	(revision 127666)
+++ fold-const.c	(working copy)
@@ -10150,9 +10150,8 @@
 	 is volatile.  */
 
       if ((! FLOAT_TYPE_P (type)
-	   || (flag_unsafe_math_optimizations
-	       && !HONOR_NANS (TYPE_MODE (type))
-	       && !HONOR_INFINITIES (TYPE_MODE (type))))
+	   || !HONOR_NANS (TYPE_MODE (type))
+	   || !HONOR_INFINITIES (TYPE_MODE (type)))
 	  && operand_equal_p (arg0, arg1, 0))
 	return fold_convert (type, integer_zero_node);
 
Index: simplify-rtx.c
===================================================================
--- simplify-rtx.c	(revision 127666)
+++ simplify-rtx.c	(working copy)
@@ -1774,9 +1774,8 @@
       if (rtx_equal_p (trueop0, trueop1)
 	  && ! side_effects_p (op0)
 	  && (! FLOAT_MODE_P (mode)
-	      || (flag_unsafe_math_optimizations
-		  && !HONOR_NANS (mode)
-		  && !HONOR_INFINITIES (mode))))
+	      || !HONOR_NANS (mode)
+	      || !HONOR_INFINITIES (mode)))
 	return CONST0_RTX (mode);
 
       /* Change subtraction from zero into negation.  (0 - x) is the