On 10/20/2021 4:28 AM, Aldy Hernandez wrote:
Sometimes we can solve a candidate path without having to recurse
further back. This can mostly happen in fully resolving mode, because
we can ask the ranger what the range on entry to the path is, but
there's no reason this can't always apply. This one-liner removes
the fully-resolving restriction.
I'm tickled pink to see how many things we now get quite early
in the compilation. I actually had to disable jump threading entirely
for a few tests because the early threader was catching things
disturbingly early. Also, as Richi predicted, I saw a lot of pre-VRP
cleanups happening.
I was going to commit this as obvious, but I think the test changes
merit discussion.
We've been playing games with gcc.dg/tree-ssa/ssa-thread-11.c for quite
some time. Every time a threading pass gets smarter, we push the
check further down the pipeline. We've officially run out of dumb
threading passes to disable ;-). In the last year we've gone up from a
handful of threads, to 34 threads with the current combination of
options. I doubt this is testing anything useful any more, so I've
removed it.
Similarly for gcc.dg/tree-ssa/ssa-dom-thread-4.c. We used to thread 3
jump threads, but they were disallowed because of loop rotation. Then
we started catching more jump threads in VRP2 threading so we tested
there. With this patch though, we triple the number of threads found
from 11 to 31. I believe this test has outlived its usefulness, and
I've removed it. Note that even though we have these outrageous
possibilities for this test, the block copier ultimately chops them
down (23 survive though).
Likewise for ssa-dom-thread-7.c. The number of threads in this test has
been growing consistently over the years. There's no way to test
what is possible, especially because improvements in one threader open
up possibilities for another. With this patch we're up to 41 registered
jump threads and they're spread over 4 passes. There's no way to get the
amount right, and this test has become a source of useless busywork.
So we want to keep some form of ssa-dom-thread-7. That' s the canonical
testcase for the case for the FSM optimization.
What we need to verify is that we thread jumps across the backedge of
the loop through the switch statement to a particular case (thus
bypassing the indirect jump for the switch statement). How to do that
in a way that's easier to manage? I have no clue. I guess a gimple-fe
based test might help.
Jeff
