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
