On Fri, Oct 22, 2021, 05:34 Jeff Law <jeffreya...@gmail.com> wrote: > > > On 10/21/2021 4:15 AM, Aldy Hernandez wrote: > > On Wed, Oct 20, 2021 at 10:19 PM Jeff Law <jeffreya...@gmail.com> wrote: > >> 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. > > Ah, I see. > > > > After lots of pain, I was able to distill a tiny testcase that does > > just that (tree-ssa/ssa-thread-backedge.c), and is easy to maintain. > > I've added a "backedge" marker to the path dumping code for easy > > matching in the test. An alternative would be to convert it to a > > gimple FE test examining the exact thread sequence through the > > backedge, but I think that's overkill since the test is so small. > Well, and the worry with a smaller testcase is reducing too far with the > result not really being representative of the issue. This actually > happened during the development of the FSM bits. I got a test from the > ARM guys, evaluated it and concluded it could be addressed with the > forward threader.... Then I did the implementation work. Once done > they said it didn't work and gave me a better testcase which had more > "join" blocks we would have had to copy to realize the important jump > threads. At which point Steve E's FSM threader was the only viable choice. > > > > > > 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. Also, we have an assert noting that we never thread through backedges in the forward threaders. It was part of the refactor. So the forward threaders can't even do it. 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'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. Ughhhh....we could put the test back, check for some random large number, and come up with a more satisfactory test later? ;-) Aldy
