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

[Richard Biener <richard.guenther@gmail.com>]

On October 24, 2021 6:57:05 PM GMT+02:00, Jeff Law via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
>
>
>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.

Well, you'd feed the specific GIMPLE to a single threading pass and check its dump file. With GIMPLE based tests you can nearly do unit testing... 

>>
>> Ughhhh....we could put the test back, check for some random large 
>> number, and come up with a more satisfactory test later? ;-)

Maybe we can dump the source location of conditions we thread through when dumping the threading pass. 

>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