RFR: 8329555: Crash in intrinsifying heap-based MemorySegment Vector store/loads [v3]

Vladimir Kozlov kvn at openjdk.org
Tue Apr 23 21:31:29 UTC 2024


On Mon, 22 Apr 2024 17:22:44 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> - Problem is related to bi-morphic inlining of ms.unsafeBase() in presence of multiple receiver type profiles (OfFloat, OfByte) which results into formation of an abstract type phi node at JVM state convergence points.
>> - Due to this, for mismatched memory segment access, inline expander is unable to infer the element type of array wrapped within the memory segment and this results into an assertion failure while computing the source lane count.
>> - For non-masked mismatched memory segment vector read/write accesses, intrinsification can continue with unknown backing storage type and compiler can skip inserting explicit reinterpretation IR after loading from or before storing to backing storage which is mandatory for semantic correctness of big-endian memory layout.
>> - For vector write access, this may prevent value forwarding, which may result into subsequent redundant vector loads from same address, but preventing intensification failure will offset that cost.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding some comments for clarity.

Looks good.

It would be interesting to look on splitting intrinsic through Phi so that we can generate vector on each branch. In separate RFE.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18749#pullrequestreview-2018339663


More information about the hotspot-compiler-dev mailing list