public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Aldy Hernandez <aldyh@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org
Subject: [gcc r13-2449] Fold __builtin_signbit to nonzero instead of 1.
Date: Mon,  5 Sep 2022 20:16:31 +0000 (GMT)	[thread overview]
Message-ID: <20220905201631.310E43858D28@sourceware.org> (raw)

https://gcc.gnu.org/g:1de9aa45529a98a5760a21570b181b78dbd11b3c

commit r13-2449-g1de9aa45529a98a5760a21570b181b78dbd11b3c
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Mon Sep 5 07:36:25 2022 +0200

    Fold __builtin_signbit to nonzero instead of 1.
    
    After Joseph's comment wrt __builtin_signbit, I have been unable to
    convince myself that arbitrarily folding __builtin_signbit () of a
    negative number to 1 is correct.
    
    For example, on the true side of x < -5.0 we know the sign bit is set,
    but on the false side, we know nothing because X may be a NAN.  I
    don't want to put ourselves in a position where the same call to
    __builtin_signbit can return two different things (1 or negative
    whatever), so I'm going to return nonzero which is correct across the
    board until someone can convince me otherwise.
    
    Setting the range to nonzero still allows us to fold conditionals
    checking __fold_builtin, while not actually propagating a 1.  Zero
    propagation still works.
    
    That being said, I still think we should be folding
    __builtin_signbit's of negative numbers to whatever the hardware
    returns, instead of 1/0 like what the front ends do.
    
    gcc/ChangeLog:
    
            * gimple-range-fold.cc
            (fold_using_range::range_of_builtin_int_call): Fold a set signbit
            in __builtin_signbit to nonzero.
    
    gcc/testsuite/ChangeLog:
    
            * gcc.dg/tree-ssa/vrp-float-signbit-2.c: New test.

Diff:
---
 gcc/gimple-range-fold.cc                           |  5 +----
 .../gcc.dg/tree-ssa/vrp-float-signbit-2.c          | 24 ++++++++++++++++++++++
 2 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/gcc/gimple-range-fold.cc b/gcc/gimple-range-fold.cc
index d8497fc9be7..3543f0980b8 100644
--- a/gcc/gimple-range-fold.cc
+++ b/gcc/gimple-range-fold.cc
@@ -1032,10 +1032,7 @@ fold_using_range::range_of_builtin_int_call (irange &r, gcall *call,
 	    if (tmp.get_signbit ().varying_p ())
 	      return false;
 	    if (tmp.get_signbit ().yes_p ())
-	      {
-		tree one = build_one_cst (type);
-		r.set (one, one);
-	      }
+	      r.set_nonzero (type);
 	    else
 	      r.set_zero (type);
 	    return true;
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/vrp-float-signbit-2.c b/gcc/testsuite/gcc.dg/tree-ssa/vrp-float-signbit-2.c
new file mode 100644
index 00000000000..954c7ebd4f8
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/vrp-float-signbit-2.c
@@ -0,0 +1,24 @@
+// { dg-do compile }
+// { dg-options "-O2 -fdump-tree-evrp" }
+
+// Test that the only thing we know about the signbit about negative number is
+// that it's not 0.
+
+void link_error ();
+
+int num;
+
+void func(float x)
+{
+  if (x < -5.0)
+    {
+      num = __builtin_signbit (x);
+
+      // We may not know the exact signbit, but we know it's not 0.
+      if (!__builtin_signbit (x))
+	link_error ();
+    }
+}
+
+// { dg-final { scan-tree-dump-not "num = \[-0-9\];" "evrp" } }
+// { dg-final { scan-tree-dump-not "link_error" "evrp" } }

                 reply	other threads:[~2022-09-05 20:16 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20220905201631.310E43858D28@sourceware.org \
    --to=aldyh@gcc.gnu.org \
    --cc=gcc-cvs@gcc.gnu.org \
    /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).