public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Aldy Hernandez <aldyh@redhat.com>
To: GCC patches <gcc-patches@gcc.gnu.org>
Cc: Jakub Jelinek <jakub@redhat.com>,
	Richard Biener <richard.guenther@gmail.com>,
	 Andrew MacLeod <amacleod@redhat.com>
Subject: Re: [RFC] Add op1_range for __builtin_signbit.
Date: Mon, 10 Oct 2022 11:42:01 +0200	[thread overview]
Message-ID: <CAGm3qMXMUzNwEvOeW2ivmCbp6SL2SuQEY5dcmJ0Bv6Vcy8YvZQ@mail.gmail.com> (raw)
In-Reply-To: <20221006105110.1719060-1-aldyh@redhat.com>

I have committed this patch, as the __builtin_signbit range-op entry
is correct.  I'd still like clarification on the folding).

Aldy

On Thu, Oct 6, 2022 at 12:51 PM Aldy Hernandez <aldyh@redhat.com> wrote:
>
> This is the op1_range range-op entry for __builtin_signbit.  It allows
> us to wind back through a call to signbit.
>
> For example, on the true side of if (__builtin_signbit(x_5) != 0) we
> can crop down the range of x_5 to:
>
>         [frange] float [-Inf, -0.0 (-0x0.0p+0)] -NAN
>
> Similarly on the false side, we can crop to:
>
>         [frange] float [0.0 (0x0.0p+0), +Inf] +NAN
>
> This brings about an interesting question, can we fold the second
> conditional here as always false?
>
>         void foo(float x)
>         {
>           if (__builtin_signbit (x))
>             {
>               if (x > 0.0)
>                 link_error();
>             }
>         }
>
> The only values for x at the second conditional are negative values,
> or -NAN, so it will always evaluate to false.  ISTM that we
> *shouldn't* fold this conditional as there is user observable behavior
> if there is a signaling NAN.  For that matter, that is exactly what we
> do in ranger-ops.  We leave the conditional in place, but ranger
> is able to determine that "x" is UNDEFINED on the path leading up to
> link_error:
>
> =========== BB 3 ============
> Imports: x_3(D)
> Exports: x_3(D)
> x_3(D)  [frange] float [-Inf, -0.0 (-0x0.0p+0)] -NAN
>     <bb 3> :
>     if (x_3(D) > 0.0)
>       goto <bb 4>; [INV]
>     else
>       goto <bb 5>; [INV]
>
> 3->4  (T) x_3(D) :      [frange] UNDEFINED
> 3->5  (F) x_3(D) :      [frange] float [-Inf, -0.0 (-0x0.0p+0)] -NAN
>
> This would allow users of ranger to query x_3 on the 3->4 and notice
> it's unreachable, without VRP removing the conditional.
>
> I believe this is correct, but would like confirmation from the experts.
>
> gcc/ChangeLog:
>
>         * gimple-range-op.cc: Add op1_range entry for __builtin_signbit.
>
> gcc/testsuite/ChangeLog:
>
>         * gcc.dg/tree-ssa/vrp-float-signbit-3.c: New test.
> ---
>  gcc/gimple-range-op.cc                        | 20 +++++++++++++++++++
>  .../gcc.dg/tree-ssa/vrp-float-signbit-3.c     | 14 +++++++++++++
>  2 files changed, 34 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/vrp-float-signbit-3.c
>
> diff --git a/gcc/gimple-range-op.cc b/gcc/gimple-range-op.cc
> index 42ebc7d6ce5..abc33e7af0c 100644
> --- a/gcc/gimple-range-op.cc
> +++ b/gcc/gimple-range-op.cc
> @@ -306,6 +306,7 @@ class cfn_signbit : public range_operator_float
>  {
>  public:
>    using range_operator_float::fold_range;
> +  using range_operator_float::op1_range;
>    virtual bool fold_range (irange &r, tree type, const frange &lh,
>                            const irange &, relation_kind) const
>    {
> @@ -320,6 +321,25 @@ public:
>        }
>     return false;
>    }
> +  virtual bool op1_range (frange &r, tree type, const irange &lhs,
> +                         const frange &, relation_kind) const override
> +  {
> +    if (lhs.zero_p ())
> +      {
> +       r.set (type, dconst0, frange_val_max (type));
> +       r.update_nan (false);
> +       return true;
> +      }
> +    if (!lhs.contains_p (build_zero_cst (lhs.type ())))
> +      {
> +       REAL_VALUE_TYPE dconstm0 = dconst0;
> +       dconstm0.sign = 1;
> +       r.set (type, frange_val_min (type), dconstm0);
> +       r.update_nan (true);
> +       return true;
> +      }
> +    return false;
> +  }
>  } op_cfn_signbit;
>
>  // Implement range operator for CFN_BUILT_IN_TOUPPER and CFN_BUILT_IN_TOLOWER.
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/vrp-float-signbit-3.c b/gcc/testsuite/gcc.dg/tree-ssa/vrp-float-signbit-3.c
> new file mode 100644
> index 00000000000..dd3090aeb10
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/vrp-float-signbit-3.c
> @@ -0,0 +1,14 @@
> +// { dg-do compile }
> +// { dg-options "-O2 -ffast-math -fdump-tree-evrp" }
> +
> +void link_error();
> +
> +void foo(float x)
> +{
> +  if (__builtin_signbit (x))
> +    {
> +      if (x > 0.0)
> +       link_error();
> +    }
> +}
> +// { dg-final { scan-tree-dump-not "link_error" "evrp" } }
> --
> 2.37.1
>


      reply	other threads:[~2022-10-10  9:42 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-06 10:51 Aldy Hernandez
2022-10-10  9:42 ` 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=CAGm3qMXMUzNwEvOeW2ivmCbp6SL2SuQEY5dcmJ0Bv6Vcy8YvZQ@mail.gmail.com \
    --to=aldyh@redhat.com \
    --cc=amacleod@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=richard.guenther@gmail.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).