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

[Emanuel Peter]

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?

Any opinions from @rwestrel ?

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

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