RFR: 8350756: C2 SuperWord Multiversioning: remove useless slow loop when the fast loop disappears [v2]

[Emanuel Peter]

On Tue, 4 Mar 2025 08:31:14 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   for Christian v1
>
> test/hotspot/jtreg/compiler/loopopts/superword/TestMultiversionRemoveUselessSlowLoop.java line 38:
> 
>> 36:  */
>> 37: 
>> 38: public class TestMultiversionRemoveUselessSlowLoop {
> 
> Is it also possible to add an IR test where we can check that a `OpaqueMultiversioning` node is first in the graph and then removed? Maybe we can check that in loop opts phase n, `COUNTED_LOOP_MAIN` and `OpaqueMultiversioning` is present. Then in loop opts phase n + 1, `COUNTED_LOOP_MAIN` is removed and in n + 2, `OpaqueMultiversioning` is removed as well. But I'm not sure if this is reliable enough when some loop opts change - though could easily be fixed or dropped again if the test fails at some point.

I thought about it. I thought it would be quite hard to get a good test for this. Especially because it depends on the flags. But maybe I can create a test that has just the right flags, make it flagless, somehow engineer that the fast main loop decays in some specific loop-opts phase, and then in the next phase things must be cleaned up.

The issue is: in the current example the slow_loop already is removed anyway. But it would be nice to have a case where after it all the fast pre loop would still be around, or the fast post loop... hmm.

Maybe I can do it with fully unrolling the fast main loop, and the slow loop does not disappear because of it. Really tricky. Do you have a good idea @chhagedorn ? How much time would you like me to invest in this?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23865#discussion_r1979004787