On 10/21/2021 9:53 PM, Aldy Hernandez wrote:
>
> Phew, I think we're finally converging on a useful set of
threading tests :).
>
> OK for trunk?
Mostly, I just worry about losing the key test for the FSM
optimization.
With the provided test, the forward threaders can't thread through the
backedge and into the switch. Disabling the other threaders was just a
precaution. I just wanted to make sure it happened late because of the
loop restrictions we have in place. I could enable the forward
threaders to prove they can't get it.
Right. There was a time when the forward threaders handled the
backedge, but it's much better handled by the backwards threader.
I could add more cases and check that we have N or more threads
through the back edges. .and if it makes you feel safer, we could even
convert the test to gimple and test the specific thread sequence. It's
just that the gimple FE test is bound to get large and difficult to
decipher if I start adding many switch cases.
I would love if we could turn the testcase into a gimple based test. I
just shudder at the thought of trying to pull that together. And yes,
it's awful hard to decipher, both in terms of test behavior and in terms
of what the key jump threads are.
I'm just trying to avoid a huge test with 40 potential threads where
no one really knows how many we should get....as every threading pass
opens up possibilities for other passes.
Understood. To some degree it's inherent in the problem. The smarter
our threaders get the more likely they are to discover new
opportunities, so there's clearly a maintenance burden to these tests
over time. It's made worse by the interactions with BRANCH_COST as well
as the heuristics for switch conversion.
Gimple based tests would significantly help the the latter issues, but I
don't know how to tackle the problem of exposing more jump threads as
our threaders get better.
Ughhhh....we could put the test back, check for some random large
number, and come up with a more satisfactory test later? ;-)
I thought our "counting" based tests could only check equality (ie,
expect to see this string precisely N times). Though if we could check
that # threads realized was > some low water mark, that'd probably be
better than what we've got right now.
jeff
