From: Jakub Jelinek <jakub@redhat.com>
To: Richard Biener <rguenther@suse.de>
Cc: gcc-patches@gcc.gnu.org, Andrew MacLeod <amacleod@redhat.com>,
Aldy Hernandez <aldyh@redhat.com>
Subject: Re: [PATCH] match.pd: Use ranges to optimize some x * y / y to x [PR97997]
Date: Thu, 26 Nov 2020 10:36:56 +0100 [thread overview]
Message-ID: <20201126093656.GU3788@tucnak> (raw)
In-Reply-To: <nycvar.YFH.7.77.849.2011260924010.7048@jbgna.fhfr.qr>
On Thu, Nov 26, 2020 at 09:24:30AM +0000, Richard Biener wrote:
> > For signed integers with undefined overflow we already optimize x * y / y
> > into x, but for signed integers with -fwrapv or unsigned integers we don't.
> > The following patch allows optimizing that into just x if value ranges
> > prove that x * y will never overflow.
> > It uses the global SSA_NAME_RANGE_INFO only, because like mentioned
> > in another PR we don't currently have a way to tell the ranger from match.pd
> > the use stmt (and we'd need in that case to tell ranger to only follow
> > SSA_NAME_DEF_STMTs + SSA_NAME_RANGE_INFO and never go in the other
> > direction, as following immediate uses seems forbidden in match.pd).
> > Another possibility would be to optimize this during vrp, but on the
> > other side the optimization itself is match.pd-ish.
> >
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> Hmm, can't you match
>
> > (div (mult@3:c @0 @1) @1)
>
> and then look at the range of @3 directly?
No. I need to check whether the multiplication will never overflow,
i.e. I need @3 range in the infinite precision (for multiplication
twice as large precision as the multiplication (when the arguments and
result have the same precision, which is the case for IL MULT_EXPR)),
while the @3 precision is that after wrapping it into the @3's precision.
So, e.g. the multiplication could always overflow, yet the range
wouldn't be VARYING, consider
@0 in [0x4000000, 0x40000ff] and @1 64, then the infinite precision
range would be [0x100000000, 0x100003fc0], but @3 range is
[0, 0x3fc0], etc. What I need to check is essentially that
__builtin_mul_overflow_p (@0, @1, (typeof (@0)) 0) folds to constant 0.
Jakub
next prev parent reply other threads:[~2020-11-26 9:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-26 8:52 Jakub Jelinek
2020-11-26 9:24 ` Richard Biener
2020-11-26 9:36 ` Jakub Jelinek [this message]
2020-11-26 13:36 ` Richard Biener
2020-11-30 15:28 ` Andrew MacLeod
2020-12-06 9:44 ` Marc Glisse
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=20201126093656.GU3788@tucnak \
--to=jakub@redhat.com \
--cc=aldyh@redhat.com \
--cc=amacleod@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=rguenther@suse.de \
/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).