RFR: 8350756: C2 SuperWord Multiversioning: remove useless slow loop when the fast loop disappears [v4]
Emanuel Peter
epeter at openjdk.org
Tue Mar 4 13:52:03 UTC 2025
On Tue, 4 Mar 2025 10:50:59 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:
>>> I'm fine with both. But I think at some point we should decide to either go with one or the other solution and not have two ways of solving a similar problem :-)
>>
>> Right, I agree we should unify the code.
>>
>>>There is code that removes elements again from the list when calling Node::destruct() and Compile::remove_useless_node():
>>
>> That's really a more complicated solution. Probably this is the best solution, which you mentioned earlier:
>>>While thinking about this, it would have been great to have a class LoopOpts where we can store all such things that should be live over multiple loop opts pass but which is then not used anymore. Anyway, that's definitely out of scope.
>>
>> Then we can just clear the relevant arrays on start of each loop-opts phase. That way we do not have to remove individual nodes, and we can still reuse the allocated memory.
>
>> Then we can just clear the relevant arrays on start of each loop-opts phase. That way we do not have to remove individual nodes, and we can still reuse the allocated memory.
>
> Yes, that would be ideal. Might be worth to further discuss this and what the impact would be.
>
> Anyway, I don't think we need to settle this now. Since zero trip guard opaque nodes already introduced a second way of doing it and there is no clear better way, I think we can use one or the other solution (your call which one) for now and visit this later again to unify the solution - hopefully with a new LoopOpts class :-) Is it worth to file an RFE now to keep track of that?
Filed:
[JDK-8351170](https://bugs.openjdk.org/browse/JDK-8351170): C2 cleanup: unify eliminate_useless_... lists
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/23865#discussion_r1979480411
More information about the hotspot-compiler-dev
mailing list