public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/110377] Early VRP and IPA-PROP should work out value ranges from __builtin_unreachable
Date: Mon, 26 Jun 2023 14:20:18 +0000	[thread overview]
Message-ID: <bug-110377-4-N4y3VEA5B7@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-110377-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110377

Andrew Macleod <amacleod at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amacleod at redhat dot com

--- Comment #2 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Jan Hubicka from comment #0)
> In the following testcase
> void test2(int);
> void
> test(int n)
> {
>         if (n > 5)
>           __builtin_unreachable ();
>         test2(n);
> }
> we should work out that value range of n passed to test2 is [INT_MIN,4].
> This would help optimizing some code in libstdc++, which now uses similar
> constructs to ensure known value ranges.

Ranger does already know this at the call site (this is output from what it
know during EVRP for instance):

=========== BB 4 ============
n_1(D)  [irange] int [-INF, 5]
    <bb 4> :
    test2 (n_1(D));
    return;

All you need to do is either query a ranger during processing of the parameter,
or tag the parameter on the call at some point..  It would be far more
effective than trying to use global ranges to communicate the information.

I had always presumed we would eventually get to the place where we can use
context sensitive range information at each call site during IPA analysis.  And
that likewise, we'd communicate back at call sites what the return range might
be when available.  (That would be a range query at the return locations of the
value on the return)

  parent reply	other threads:[~2023-06-26 14:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-23 15:37 [Bug middle-end/110377] New: Early VRP and IPA-PROP should work out value ranges from __builtin_unreacahble hubicka at gcc dot gnu.org
2023-06-26  8:56 ` [Bug middle-end/110377] Early VRP and IPA-PROP should work out value ranges from __builtin_unreachable rguenth at gcc dot gnu.org
2023-06-26 14:20 ` amacleod at redhat dot com [this message]
2023-06-26 16:48 ` hubicka at gcc dot gnu.org
2023-06-26 19:49 ` amacleod at redhat dot com
2023-06-27  7:45 ` hubicka at gcc dot gnu.org
2023-06-28  7:35 ` cvs-commit at gcc dot gnu.org
2023-11-21 15:12 ` hubicka at gcc dot gnu.org

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=bug-110377-4-N4y3VEA5B7@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@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).