RFR: 8371964: C2 compilation asserts with "Unexpected load/store size" [v3]

[Roland Westrelin]

On Tue, 25 Nov 2025 17:46:28 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Is this issue at all related to https://github.com/openjdk/jdk/pull/24575?
>> 
>> It seems we remove a `CastLL` from the graph, because the input type is wider than the Cast's type, right?
>> 
>> If I remember correctly from https://github.com/openjdk/jdk/pull/24575, if a CastLL is narrowing, we don't want to remove it, see `ConstraintCastNode::Identity`.
>> 
>> Can you elaborate a bit more on where the `CastLL` came from, and what it is supposed to do?
>
> @eme64 Yes, it is indeed similar. The issue here is that after loop opts, we try to remove almost all `CastNode`s so that the graph can be GVN-ed better (think of `x = a + b` and `y = cast(a) + b`).
> 
>> Can you elaborate a bit more on where the `CastLL` came from, and what it is supposed to do?
> 
> Macro expansion tries to be smart for an array copy and does this:
> 
>     byte[] dst;
>     byte[] src;
>     int len;
>     if (len <= 32) {
>         int casted_len = cast(len, 0, 32);
>         vectormask<byte, 32> mask = VectorMaskGen(casted_len);
>         vector<byte, 32> v = LoadVectorMasked(src, 0, mask);
>         StoreVectorMasked(dst, 0, v, mask);
>     } else {
>         // do the copy normally;
>     }
> 
> As you can see, the masked accesses are only meaningful if `len <= 32`. But after loop opts, the cast is gone, leaving us with a len which happens to be larger than `32`. The path should be dead, but IGVN reaches the `LoadVectorMaskedNode` first, which triggers the assert.

> @merykitty Thanks for the explanations! So the `CastLL` is a narrowing cast, right? And `ConstraintCastNode::Identity` removes it, because the input type is wider, right? To me this part sounds incorrect. Narrowing casts should only be removed if the input is already narrower. No?

But the type of the CastLL is widened after loop opts, right?
So it's similar to https://github.com/openjdk/jdk/pull/24575 but with a constant input to the cast. That's a case that #24575 doesn't address (it doesn't prevent constant folding of a cast) and can cause issues. See https://github.com/openjdk/jdk/pull/24575#issuecomment-3356091219 
I intend to create a follow up to 24575 that will address the remaining issues in a way that's similar to what @merykitty proposes here.

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

PR Comment: https://git.openjdk.org/jdk/pull/28410#issuecomment-3580754379