This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][PR tree-optimization/67816] Fix jump threading when DOM removes conditionals in jump threading path
- From: Jeff Law <law at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 2 Dec 2015 08:31:37 -0700
- Subject: Re: [PATCH][PR tree-optimization/67816] Fix jump threading when DOM removes conditionals in jump threading path
- Authentication-results: sourceware.org; auth=none
- References: <561482CD dot 6060202 at redhat dot com> <CAFiYyc06BQ0ruypjODUSLNvawRYSKSUZxDqV-MdshKZwmpgPgw at mail dot gmail dot com> <56159608 dot 5000801 at redhat dot com> <CAFiYyc1zCHN40QSs=GH7bzJ35EJvYHk2pGv6HZabq5EkU2LTXw at mail dot gmail dot com> <5617E10E dot 6060300 at redhat dot com> <565E11EF dot 4080605 at redhat dot com> <CAFiYyc2mv=-wahHY++d=7VjuDn6oO=vnzpSu-bQJVj6Arfyxyw at mail dot gmail dot com>
On 12/02/2015 02:54 AM, Richard Biener wrote:
Deferring to cfg_cleanup works because if cfg_cleanup does anything, it sets
LOOPS_NEED_FIXUP (which we were trying to avoid in DOM). So it seems that
the gyrations we often do to avoid LOOPS_NEED_FIXUP are probably not all
that valuable in the end. Anyway...
Yeah, I have partially working patches lying around to "fix" CFG cleanup to
avoid this. Of course in the case of new loops appearing that's not easily
possible.
And that may argue that it's largely inevitable if we collapse a
conditional (and thus delete an edge).
There's some fallout which I'm still exploring. For example, we have cases
where removal of the edge by DOM results in removal of a PHI argument in the
target, which in turn results in the PHI becoming a degenerate which we can
then propagate away. I have a possible solution for this that I'm playing
with.
I suspect the right path is to continue down this path.
Yeah, the issue here is that DOM isn't tracking which edges are executable
to handle merge PHIs (or to aovid doing work in unreachable regions).
Right.
It should
be possible to make it do that much like I extended SCCVN to do this
(when doing the DOM walk see if any incoming edge is marked executable
and if not, mark all outgoing edges as not executable, if the block is
executable
at the time we process the last stmt determine if we can compute the edge
that ends up always executed and mark all others as not executable)
Essentially yes. I'm using the not-executable flag and bypassing things
when it's discovered.
The most interesting side effect, and one I haven't fully analyzed yet
is an unexpected jump thread -- which I've traced back to differences in
what the alias oracle is able to find when we walk unaliased vuses.
Which makes totally no sense that it's unable to find the unaliased vuse
in the simplified CFG, but finds it when we don't remove the
unexecutable edge. As I said, it makes no sense to me yet and I'm still
digging.
jeff