RFR: 8351468: C2: array fill optimization assigns wrong type to intrinsic call

Quan Anh Mai qamai at openjdk.org
Fri Mar 14 11:54:58 UTC 2025


On Fri, 14 Mar 2025 09:54:53 GMT, Roberto Castañeda Lozano <rcastanedalo at openjdk.org> wrote:

>> @robcasloz I disagree, I would expect the `memory_type` of a `StoreC` into a `long[]` to be something that means "a part of a `long[]`", which should be `T_LONG` if the store is guaranteed to be enclosed in a single `long`, or `T_VOID` otherwise. While we are trying to store 2 bytes into the memory, the thing in the memory is neither a `short` nor a `char`.
>
>> I would expect the `memory_type` of a `StoreC` into a `long[]` to be something that means "a part of a `long[]`"
> 
> If that was the intended meaning of `MemNode::memory_type()`, wouldn't the function be redundant, because we can retrieve that information from `MemNode::adr_type()` already?

@robcasloz Yes that's right. Then `MemNode::memory_type()` does not refer to the thing in memory at all, but the thing that is about to interact with the memory. I think:

- We should rename it to `MemNode::value_type()` or `MemNode::value_basic_type()`
- It is simply incorrect to use it to reason about the thing in the memory in this problem, and using `adr_type` is the correct fix.

To be clear, I don't think having `StoreSNode` would solve any issue. I can `StoreS` into a `char[]`, and `StoreC` into a `short[]` and we are back at the same issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/24005#issuecomment-2724445592


More information about the hotspot-compiler-dev mailing list