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 Hold off with integration for a few hours, @chhagedorn just launched some internal testing.

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

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