https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78496
--- Comment #6 from Jeffrey A. Law <law at redhat dot com> ---
So I've got a hack that allows me to evaluate the effect of the last example
from c#5. So let's look at how the number of realized jump threads is affected
by the various tweaks I'm playing with:
VRP1 DOM2 DOM3 VRP2 thread{1,2,3,4}
base 6 9 0 0 0
p1 27 9 3 0 0
p2 30 6 0 21 0
p3 51 6 0 0 0
p4 51 6 0 0 6
VRP/DOM/thread columns count the number of jump threads realized by that pass.
p1 defers simplification of conditionals until after VRP threading is done.
It's clearly finding many previously missed jump threads and even exposes some
new opportunities for DOM3.
p2 simplifies ASSERT_EXPRs from relational to equality tests. It moves a small
number of jump threads from DOM into VRP1, and also picks up a ton of new jump
threads to VRP2.
p3 catches the case in the last example of c#5. It moves all those cases
exposed for VRP2 by patch #2 to occur in VRP1.
p4 retunes the FSM threader slightly. I'm still experimenting here, but it
does catch some stuff that was previously missed *and* exposes some new
opportunities. Ie, it catches stuff in thread2 and exposes stuff for thread3.
It's pretty clear that the patches can significantly improve the jump threading
we're doing for this testcase and do so early in the pipeline, where they're
the most beneficial.
We don't have a good description of the primary effect we're looking for, but
I'll guess that we're finding partial redundancies for those edges with
constant PHI arguments. Many of those should just go away completely. If we
look at the pre dumps, we start with 278 partial redundancies. The first patch
drops that to 73. The second patch drops it further to 61 where it stabilizes.
So we're certainly seeing a lot fewer partial redundancies.
