public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [RFC PATCH] range-op-float: Only flush_denormals_to_zero for +-*/ [PR109154]
@ 2023-03-28  8:16 Jakub Jelinek
  2023-03-28  8:49 ` Aldy Hernandez
  0 siblings, 1 reply; 2+ messages in thread
From: Jakub Jelinek @ 2023-03-28  8:16 UTC (permalink / raw)
  To: Aldy Hernandez, Andrew MacLeod; +Cc: gcc-patches

Hi!

As discussed in the PR, flushing denormals to zero on every frange::set
might be harmful for e.g. x < 0.0 comparisons, because we then on both
sides use ranges that include zero [-Inf, -0.0] on the true side, and
[-0.0, +Inf] NAN on the false side, rather than [-Inf, nextafter (-0.0, -Inf)]
on the true side.

The following patch does it only in range_operator_float::fold_range
which is right now used for +-*/ (both normal and reverse ops of those).

Though, I don't see any difference on the testcase in the PR, but not sure
what I should be looking at and the reduced testcase there has undefined
behavior.

Anyway, bootstrapped/regtested on x86_64-linux and i686-linux.

If it doesn't help with the PR, could be as well deferred for stage 1.

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

	PR tree-optimization/109154
	* value-range.h (frange::flush_denormals_to_zero): Make it public
	rather than private.
	* value-range.cc (frange::set): Don't call flush_denormals_to_zero
	here.
	* range-op-float.cc (range_operator_float::fold_range): Call
	flush_denormals_to_zero.

--- gcc/value-range.h.jj	2023-03-23 15:25:47.059741131 +0100
+++ gcc/value-range.h	2023-03-27 18:56:35.164190929 +0200
@@ -373,6 +373,7 @@ public:
   void update_nan (tree) = delete; // Disallow silent conversion to bool.
   void update_nan (const nan_state &);
   void clear_nan ();
+  void flush_denormals_to_zero ();
 
   // fpclassify like API
   bool known_isfinite () const;
@@ -389,7 +390,6 @@ private:
   bool union_nans (const frange &);
   bool intersect_nans (const frange &);
   bool combine_zeros (const frange &, bool union_p);
-  void flush_denormals_to_zero ();
 
   tree m_type;
   REAL_VALUE_TYPE m_min;
--- gcc/value-range.cc.jj	2023-03-27 12:50:45.876826415 +0200
+++ gcc/value-range.cc	2023-03-27 18:45:50.127495492 +0200
@@ -361,8 +361,6 @@ frange::set (tree type,
 
   normalize_kind ();
 
-  flush_denormals_to_zero ();
-
   if (flag_checking)
     verify_range ();
 }
--- gcc/range-op-float.cc.jj	2023-03-27 13:28:18.847264635 +0200
+++ gcc/range-op-float.cc	2023-03-27 18:50:24.498537727 +0200
@@ -112,6 +112,8 @@ range_operator_float::fold_range (frange
 	}
     }
 
+  r.flush_denormals_to_zero ();
+
   return true;
 }
 

	Jakub


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [RFC PATCH] range-op-float: Only flush_denormals_to_zero for +-*/ [PR109154]
  2023-03-28  8:16 [RFC PATCH] range-op-float: Only flush_denormals_to_zero for +-*/ [PR109154] Jakub Jelinek
@ 2023-03-28  8:49 ` Aldy Hernandez
  0 siblings, 0 replies; 2+ messages in thread
From: Aldy Hernandez @ 2023-03-28  8:49 UTC (permalink / raw)
  To: Jakub Jelinek, Andrew MacLeod; +Cc: gcc-patches



On 3/28/23 10:16, Jakub Jelinek wrote:
> Hi!
> 
> As discussed in the PR, flushing denormals to zero on every frange::set
> might be harmful for e.g. x < 0.0 comparisons, because we then on both
> sides use ranges that include zero [-Inf, -0.0] on the true side, and
> [-0.0, +Inf] NAN on the false side, rather than [-Inf, nextafter (-0.0, -Inf)]
> on the true side.
> 
> The following patch does it only in range_operator_float::fold_range
> which is right now used for +-*/ (both normal and reverse ops of those).
> 
> Though, I don't see any difference on the testcase in the PR, but not sure
> what I should be looking at and the reduced testcase there has undefined
> behavior.
> 
> Anyway, bootstrapped/regtested on x86_64-linux and i686-linux.

LGTM.
Aldy

> 
> If it doesn't help with the PR, could be as well deferred for stage 1.
> 
> 2023-03-28  Jakub Jelinek  <jakub@redhat.com>
> 
> 	PR tree-optimization/109154
> 	* value-range.h (frange::flush_denormals_to_zero): Make it public
> 	rather than private.
> 	* value-range.cc (frange::set): Don't call flush_denormals_to_zero
> 	here.
> 	* range-op-float.cc (range_operator_float::fold_range): Call
> 	flush_denormals_to_zero.
> 
> --- gcc/value-range.h.jj	2023-03-23 15:25:47.059741131 +0100
> +++ gcc/value-range.h	2023-03-27 18:56:35.164190929 +0200
> @@ -373,6 +373,7 @@ public:
>     void update_nan (tree) = delete; // Disallow silent conversion to bool.
>     void update_nan (const nan_state &);
>     void clear_nan ();
> +  void flush_denormals_to_zero ();
>   
>     // fpclassify like API
>     bool known_isfinite () const;
> @@ -389,7 +390,6 @@ private:
>     bool union_nans (const frange &);
>     bool intersect_nans (const frange &);
>     bool combine_zeros (const frange &, bool union_p);
> -  void flush_denormals_to_zero ();
>   
>     tree m_type;
>     REAL_VALUE_TYPE m_min;
> --- gcc/value-range.cc.jj	2023-03-27 12:50:45.876826415 +0200
> +++ gcc/value-range.cc	2023-03-27 18:45:50.127495492 +0200
> @@ -361,8 +361,6 @@ frange::set (tree type,
>   
>     normalize_kind ();
>   
> -  flush_denormals_to_zero ();
> -
>     if (flag_checking)
>       verify_range ();
>   }
> --- gcc/range-op-float.cc.jj	2023-03-27 13:28:18.847264635 +0200
> +++ gcc/range-op-float.cc	2023-03-27 18:50:24.498537727 +0200
> @@ -112,6 +112,8 @@ range_operator_float::fold_range (frange
>   	}
>       }
>   
> +  r.flush_denormals_to_zero ();
> +
>     return true;
>   }
>   
> 
> 	Jakub
> 


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2023-03-28  8:49 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-28  8:16 [RFC PATCH] range-op-float: Only flush_denormals_to_zero for +-*/ [PR109154] Jakub Jelinek
2023-03-28  8:49 ` Aldy Hernandez

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).