RFR: 8356176: C2 MemorySegment: missing RCE with byteSize() in Loop Exit Check inside the for Expression [v3]

[Emanuel Peter]

On Tue, 12 Aug 2025 14:39:35 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> src/hotspot/share/opto/loopnode.hpp line 1673:
>> 
>>> 1671:     // dependant node, i.e. spliting a Bool node after splitting a Cmp node.
>>> 1672:     bool profitable(int policy) const {
>>> 1673:       return policy < 0 || (_loop_entry_wins == 0 && _total_wins > policy) || _loop_back_wins > policy;
>> 
>> This already looks better. I'm wondering if we can still improve the readability a bit. Why not group the descriptions with the corresponding conditions?
>> 
>> 
>>     // In general this means that the split has to have more wins than specified
>>     // in the policy. In loops, we need to be careful when splitting, because it
>>     // can sufficiently rearrange the loop structure to prevent RCE and thus
>>     // vectorization. Thus, we only deem splitting profitable if the win of a
>>     // split is not on the entry edge, as such wins only pay off once and have
>>     // a high chance of messing up the loop structure.
>> 
>> This seems to go with condition
>> `(_loop_entry_wins == 0 && _total_wins > policy)`
>> 
>> 
>>     // in the policy. In loops, we need to be careful when splitting, because it
>>     // can sufficiently rearrange the loop structure to prevent RCE and thus
>>     // vectorization.
>> 
>> Maybe we can restate the argument a little, and make it more explicit what kinds of rearrangements are problematic here? Maybe an example could help. What is it exactly that we risk loosing here?
>> 
>> 
>>     // vectorization. Thus, we only deem splitting profitable if the win of a
>>     // split is not on the entry edge, as such wins only pay off once and have
>>     // a high chance of messing up the loop structure.
>> 
>> How is this impacted if we have wins on both the entry and the backedge? Is that possible? Do we have any benchmarks here?
>> It would be nice if we could say that if we **only** had entry wins and no backedge wins, then it's ok to not split, because this win would only have happened once per loop execution. But as soon as we have wins on the backedge, it would be profitable to split, and we should do so, right?
>> 
>> 
>>     // a high chance of messing up the loop structure. However, if there are
>>     // wins on the entry edge and also sufficient wins on the backadge, which
>>     // pay off on every iteration, a split is also deemed profiable.
>> 
>> Ah, you are arguing about that here actually. Must be about this condition:
>> `_loop_back_wins > policy`
>> 
>> You see, I'm struggling a bit to follow here and have to reconstruct it ;)
>
>> How is this impacted if we have wins on both the entry and the backedge? Is that possible? Do we have any benchmarks here?
> 
> In general, we ignore the wins on the entry. So it is profitable if the wins on the loop back is greater than the threshold.

Sure, I gathered as much. It would still be nice to have some examples / IR-tests / JMH-benchmarks here. Just to make sure we are getting the conditions right.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26429#discussion_r2270173531