RFR: 8373591: C2: Fix the memory around some intrinsics nodes [v5]

[Dean Long]

On Wed, 7 Jan 2026 09:42:22 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This is extracted from #28570 , there are 2 issues here:
>> 
>> - Some intrinsics nodes advertise incorrect `adr_type`. For example, `AryEqNode` reports `adr_type` being `TypeAryPtr::BYTES` (it inherits this from `StrIntrinsicNode`). This is incorrect, however, as it can accept `char[]` inputs, too. Another case is `VectorizedHashCodeNode`, which reports its `adr_type` being `TypePtr::BOTTOM`, but it actually extracts a memory slice and does not consume the whole memory.
>> - For nodes such as `StrInflatedCopyNode`, as they consume more than they produce, during scheduling, we need to compute anti-dependencies. This is not the case, so we should fix it by making the nodes kill all the memory they consume. This issue is often not present because these intrinsics are not exposed bare to general usage.
>> 
>> Please kindly review, thanks a lot.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into intrinsicsadrtype
>  - copyright year
>  - Merge branch 'master' into intrinsicsadrtype
>  - consolidate the memory effect into a function
>  - Use MemBar instead of widening the intrinsic memory
>  - Fix Shenandoah
>  - Fix memory around intrinsics nodes

This may be unrelated, but I checked to see if we treat Op_EncodeISOArray the same as Op_StrCompressedCopy everywhere.  In two places in `ConnectionGraph::split_unique_types`, we treat them differently.  For both we look at in(MemNode::Memory), but for Op_EncodeISOArray we also look at use->in(3).  I don't understand this code well enough to decide if this a missing optimization or a correctness issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/28789#issuecomment-3821462990