Re: [PATCH] Try to resolve paths in threader without looking further back.

[Jeff Law <jeffreyalaw@gmail.com>]

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