RFR: 8370405: C2: mismatched store from MergeStores wrongly scalarized in allocation elimination [v2]

[Emanuel Peter]

On Wed, 29 Oct 2025 17:47:52 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Emanuel Peter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8370405-alloc-elimination-and-MergeStores
>>  - only verify primitive types
>>  - Apply suggestions from code review
>>  - more assert adjustment
>>  - ignore debug flag
>>  - id for tests, and fix up the assert
>>  - pass int for short slot
>>  - another test
>>  - improve test
>>  - wip new IR test
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/617bfc00...b6e032c2
>
> And I am fine to do that in separate changes.

@vnkozlov Thanks for the additional ideas and clarifications.

> I suggest to not execute MergeStores for stores associated with allocation marked _is_scalar_replaceable.

Right. We could keep things as they are now: EA analysis (mark stores scalar replacable), then MergeStores (but avoid scalar replacable stores), then do allocation elimination (if possoible, and no related store is still in a loop, for example).
Downside: if allocation elimination still fails, we would perform neither allocation elimination nor MergeStores.

The best course of action is to try to push MergeStores as late as possible, to disentangle it from other optimizations.
We have already had to move MergeStores from post-loop-opts to a separate later phase: https://github.com/openjdk/jdk/pull/23944
So this would just be taking a further step into that direction.

So where would I move `process_for_merge_stores_igvn` in that follow-up RFE?
- After macro expansion?
- After Barrier expansion?
- After `optimize_logic_cones`?
- After `process_late_inline_calls_no_inline`?

Later is not possible, because (at least for now), we do need igvn. We could also try to go later, but that would require detaching MergeStores from IGVN, and would take a bit of a redesign.

FYI: there was a PR for extending to `MergeLoads`: https://github.com/openjdk/jdk/pull/24023
In connection with that, we already considered refactoring MergeStores to avoid reliance on IGVN, and so we could push the optimization even later.

The question is a bit how much time I should spend on this. Just moving `process_for_merge_stores_igvn` a little later is very little effort (just move the line, and some thorough testing). Refactoring to avoid IGVN is much more effort.

What do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/27997#issuecomment-3466352871