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

[Roland Westrelin]

On Wed, 26 Nov 2025 10:52:14 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> @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.

> @rwestrel Is there any conflict with your solution? If not, we can go ahead with @merykitty 's solution here.

No, no conflict.

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

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