From: Aldy Hernandez <aldyh@redhat.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: Jeff Law <jeffreyalaw@gmail.com>,
Jakub Jelinek <jakub@redhat.com>,
GCC patches <gcc-patches@gcc.gnu.org>,
Andrew MacLeod <amacleod@redhat.com>
Subject: Re: [PATCH] Convert strlen pass from evrp to ranger.
Date: Thu, 21 Oct 2021 14:56:11 +0200 [thread overview]
Message-ID: <CAGm3qMUoBXOJw6D9BrQOL3fo5205hyW11iDHD2Q65KcLbPC76A@mail.gmail.com> (raw)
In-Reply-To: <CAFiYyc1royUQWwiQhxUbWXPhLQteeChSi_O7JXfScHDts2vCHQ@mail.gmail.com>
On Thu, Oct 21, 2021 at 12:20 PM Richard Biener
<richard.guenther@gmail.com> wrote:
>
> On Wed, Oct 20, 2021 at 10:58 PM Jeff Law <jeffreyalaw@gmail.com> wrote:
> >
> >
> >
> > On 10/18/2021 2:17 AM, Aldy Hernandez wrote:
> > >
> > >
> > > On 10/18/21 12:52 AM, Jeff Law wrote:
> > >>
> > >>
> > >> On 10/8/2021 9:12 AM, Aldy Hernandez via Gcc-patches wrote:
> > >>> The following patch converts the strlen pass from evrp to ranger,
> > >>> leaving DOM as the last remaining user.
> > >> So is there any reason why we can't convert DOM as well? DOM's use
> > >> of EVRP is pretty limited. You've mentioned FP bits before, but my
> > >> recollection is those are not part of the EVRP analysis DOM uses.
> > >> Hell, give me a little guidance and I'll do the work...
> > >
> > > Not only will I take you up on that offer, but I can provide 90% of
> > > the work. Here be dragons, though (well, for me, maybe not for you ;-)).
> > >
> > > DOM is actually an evrp pass at -O1 in disguise. The reason it really
> > > is a covert evrp pass is because:
> > >
> > > a) It calls extract_range_from_stmt on each statement.
> > >
> > > b) It folds conditionals with simplify_using_ranges.
> > >
> > > c) But most importantly, it exports discovered ranges when it's done
> > > (evrp_range_analyzer(true)).
> > >
> > > If you look at the evrp pass, you'll notice that that's basically what
> > > it does, albeit with the substitute and fold engine, which also calls
> > > gimple fold plus other goodies.
> > >
> > > But I could argue that we've made DOM into an evrp pass without
> > > noticing. The last item (c) is particularly invasive because these
> > > exported ranges show up in other passes unexpectedly. For instance, I
> > > saw an RTL pass at -O1 miss an optimization because it was dependent
> > > on some global range being set. IMO, DOM should not export global
> > > ranges it discovered during its walk (do one thing and do it well),
> > > but I leave it to you experts to pontificate.
> > All true. But I don't think we've got many, if any, hard dependencies
> > on those behaviors.
> >
> > >
> > > The attached patch is rather trivial. It's mostly deleting state. It
> > > seems DOM spends a lot of time massaging the IL so that it can fold
> > > conditionals or thread paths. None of this is needed, because the
> > > ranger can do all of this. Well, except floats, but...
> > Massaging the IL should only take two forms IIRC.
> >
> > First, if we have a simplification we can do. That could be const/copy
> > propagation, replacing an expression with an SSA_NAME or constant and
> > the like. It doesn't massage the IL just to massage the IL.
> >
> > Second, we do temporarily copy propagate the current known values of an
> > SSA name into use points and then see if that allows us to determine if
> > a statement is already in the hash tables. But we undo that so that
> > nobody should see that temporary change in state.
>
> Are you sure we still do that? I can't find it at least.
I couldn't either, but perhaps what Jeff is referring to is the ad-hoc
copy propagation that happens in the DOM's use of the threader:
/* Make a copy of the uses & vuses into USES_COPY, then cprop into
the operands. */
FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, SSA_OP_ALL_USES)
{
tree tmp = NULL;
tree use = USE_FROM_PTR (use_p);
copy[i++] = use;
if (TREE_CODE (use) == SSA_NAME)
tmp = SSA_NAME_VALUE (use);
if (tmp)
SET_USE (use_p, tmp);
}
cached_lhs = simplifier->simplify (stmt, stmt, bb, this);
/* Restore the statement's original uses/defs. */
i = 0;
FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, SSA_OP_ALL_USES)
SET_USE (use_p, copy[i++]);
Aldy
next prev parent reply other threads:[~2021-10-21 12:56 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-08 15:12 Aldy Hernandez
2021-10-08 16:51 ` Martin Sebor
2021-10-08 17:56 ` Andrew MacLeod
2021-10-08 20:27 ` Martin Sebor
2021-10-09 15:04 ` Aldy Hernandez
2021-10-09 16:19 ` Martin Sebor
2021-10-09 17:59 ` Martin Sebor
2021-10-11 6:54 ` Aldy Hernandez
2021-10-09 18:47 ` Aldy Hernandez
2021-10-14 22:07 ` Martin Sebor
2021-10-14 23:45 ` Jeff Law
2021-10-15 0:47 ` Andrew MacLeod
2021-10-15 10:39 ` Aldy Hernandez
2021-10-17 22:49 ` Jeff Law
2021-10-18 7:43 ` Aldy Hernandez
2021-10-22 11:11 ` Aldy Hernandez
2021-10-29 20:04 ` Aldy Hernandez
2021-11-09 0:09 ` Jeff Law
2021-10-17 22:52 ` Jeff Law
2021-10-18 8:17 ` Aldy Hernandez
2021-10-20 20:58 ` Jeff Law
2021-10-21 7:42 ` Aldy Hernandez
2021-10-21 18:20 ` Jeff Law
2021-10-23 21:32 ` Jeff Law
2021-10-25 1:59 ` Jeff Law
2021-10-21 10:20 ` Richard Biener
2021-10-21 12:56 ` Aldy Hernandez [this message]
2021-10-21 13:14 ` Richard Biener
2021-10-21 13:30 ` Aldy Hernandez
2021-10-21 13:46 ` Richard Biener
2021-10-21 14:17 ` Aldy Hernandez
2021-10-21 13:43 ` Jeff Law
2021-10-21 14:18 ` Aldy Hernandez
2021-10-25 2:15 ` Jeff Law
2021-10-25 4:42 ` Jeff Law
2021-10-25 11:27 ` Aldy Hernandez
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=CAGm3qMUoBXOJw6D9BrQOL3fo5205hyW11iDHD2Q65KcLbPC76A@mail.gmail.com \
--to=aldyh@redhat.com \
--cc=amacleod@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=jeffreyalaw@gmail.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).