RFR: 8318446: C2: optimize stores into primitive arrays by combining values into larger store

[Emanuel Peter]

On Thu, 21 Mar 2024 22:48:01 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>>>     * No RangeCheck smearing, or other CFG between the stores: `RC[0], store[0], RC[1], store[1], RC[2], store[2], RC[3], store[3]`. Not so simple. We can merge the 4 stores on the normal path, where all RC's pass. But we have to remove all old stores from that path. But the `RC[1], RC[2], RC[3]` false paths need some of those stores. So the only way I see is to duplicate all stores for the branches, so that we are sure that they sink out into the trap-paths.
>> 
>> I also think you need to duplicate stores. My opinion is that we want to stick with the simpler cases (your first and second bullets) unless it's obvious it doesn't cover all use cases. It's always possible to revisit the optimization down the road if it's observed that there are cases that are not covered.
>
>> > ```
>> > * No RangeCheck smearing, or other CFG between the stores: `RC[0], store[0], RC[1], store[1], RC[2], store[2], RC[3], store[3]`. Not so simple. We can merge the 4 stores on the normal path, where all RC's pass. But we have to remove all old stores from that path. But the `RC[1], RC[2], RC[3]` false paths need some of those stores. So the only way I see is to duplicate all stores for the branches, so that we are sure that they sink out into the trap-paths.
>> > ```
>> 
>> I also think you need to duplicate stores. My opinion is that we want to stick with the simpler cases (your first and second bullets) unless it's obvious it doesn't cover all use cases. It's always possible to revisit the optimization down the road if it's observed that there are cases that are not covered.
> 
> I completely agree with Roland.

@vnkozlov @rwestrel @TobiHartmann I refactored the code significantly, I think it is now much more well structured.
I also only allow a singe RangeCheck now, that makes sure that the "first" store floats towards the uncommon trap.

Feel free to re-review. I'm out of the office next week, and will return to this then, and re-run the benchmarks.

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

PR Comment: https://git.openjdk.org/jdk/pull/16245#issuecomment-2039489405