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

[Quan Anh Mai]

On Tue, 25 Nov 2025 13:07:54 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reviews
>
> 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.

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

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