From: Aldy Hernandez <aldyh@redhat.com>
To: Jakub Jelinek <jakub@redhat.com>, Andrew MacLeod <amacleod@redhat.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [RFC PATCH] range-op-float: Only flush_denormals_to_zero for +-*/ [PR109154]
Date: Tue, 28 Mar 2023 10:49:11 +0200 [thread overview]
Message-ID: <f114d34d-a391-e845-79b6-63fdcf24a423@redhat.com> (raw)
In-Reply-To: <ZCKiZDm40JqnmjZi@tucnak>
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
>
prev parent reply other threads:[~2023-03-28 8:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-28 8:16 Jakub Jelinek
2023-03-28 8:49 ` Aldy Hernandez [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f114d34d-a391-e845-79b6-63fdcf24a423@redhat.com \
--to=aldyh@redhat.com \
--cc=amacleod@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).