JDK-8331576 : C2 SuperWord: Unsafe access with long address that is a CastX2P does not vectorize
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 23
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2024-05-02
  • Updated: 2025-06-06
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8330991 - C2 SuperWord: refactor VPointer
Relates :  
JDK-8343685 - C2 SuperWord: refactor VPointer with MemPointer
Description
Attached file, here the commandline:

The issue is that the VPointer wants the address to be a AddP. But in this case, it directly gets a CastX2P, which it does currently not parse through.

./java --add-modules java.base --add-exports java.base/jdk.internal.misc=ALL-UNNAMED --add-exports java.base/jdk.internal.util=ALL-UNNAMED -XX:CompileCommand=compileonly,Test*::* -XX:CompileCommand=printcompilation,TestMemorySegment::* -XX:CompileCommand=TraceAutoVectorization,Test*::*,SW_REJECTIONS,PRECONDITIONS,POINTERS -XX:+TraceNewVectors -XX:+TraceLoopOpts -Xbatch TestUnsafeAllocateLongAdr.java
Comments
Quickly looked at it again: ./java --add-modules java.base --add-exports java.base/jdk.internal.misc=ALL-UNNAMED --add-exports java.base/jdk.internal.util=ALL-UNNAMED -XX:CompileCommand=compileonly,Test*::* -XX:CompileCommand=printcompilation,TestMemorySegment::* -XX:CompileCommand=TraceAutoVectorization,Test*::*,SW_REJECTIONS,PRECONDITIONS,POINTERS,POINTER_PARSING -XX:+TraceNewVectors -XX:+TraceLoopOpts -Xbatch TestUnsafeAllocateLongAdr.java VPointer[size: 8, object, base(38 CastPP) + con( 64) + iv_scale( 8) * iv + invar(0)] VPointer[size: 8, object, base(38 CastPP) + con( 24) + iv_scale( 8) * iv + invar(0)] VPointer[size: 8, object, base(38 CastPP) + con( 16) + iv_scale( 8) * iv + invar(0)] VPointer[size: 8, object, base(38 CastPP) + con( 40) + iv_scale( 8) * iv + invar(0)] VPointer[size: 8, object, base(38 CastPP) + con( 32) + iv_scale( 8) * iv + invar(0)] VPointer[size: 8, object, base(38 CastPP) + con( 56) + iv_scale( 8) * iv + invar(0)] VPointer[size: 8, object, base(38 CastPP) + con( 48) + iv_scale( 8) * iv + invar(0)] VPointer[size: 8, object, base(38 CastPP) + con( 72) + iv_scale( 8) * iv + invar(0)] VPointer[invalid] VPointer[invalid] VPointer[invalid] VPointer[invalid] VPointer[invalid] VPointer[invalid] VPointer[invalid] VPointer[invalid] The array pointers can be parsed, but not the unsafe pointer. Example output: MemPointerParser::parse: mem: 469 StoreL === 593 477 470 473 [[ 398 ]] @rawptr:BotPTR, idx=Raw; unaligned unsafe Memory: @rawptr:BotPTR, idx=Raw; !orig=146,416 !jvms: TestUnsafeAllocateLongAdr::test @ bci:23 (line 17) MemPointer[size: 8, base: native 655 CastX2P, form: 40 + 1 * [655 CastX2P]] raw: 1L * [655 CastX2P] + 40L dist dump --------------------------------------------- 7 605 ConI === 0 [[ 344 147 608 ]] #int:8 7 55 ConI === 0 [[ 56 67 78 89 388 450 238 265 310 ]] #int:1 7 448 CastII === 342 321 [[ 450 ]] #int:0..max-1:www unconditional dependency !orig=[386] 6 147 AddI === _ 592 605 [[ 329 177 592 185 ]] !orig=[176],... !jvms: TestUnsafeAllocateLongAdr::test @ bci:26 (line 16) 6 450 AddI === _ 448 55 [[ 592 ]] !orig=[386] 5 592 Phi === 593 450 147 [[ 640 588 589 590 591 147 633 636 638 ]] #int:1..max-1:www #tripcount !orig=490,408,107,[221],[135] !jvms: TestUnsafeAllocateLongAdr::test @ bci:8 (line 17) 4 3 Start === 3 0 [[ 3 5 6 7 8 9 10 12 ]] #{0:control, 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address, 5:long, 6:half, 7:long[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact *} 4 115 ConI === 0 [[ 645 245 317 647 650 652 566 571 579 586 ]] #int:3 4 633 ConvI2L === _ 592 [[ 650 ]] #long:1..maxint-6:www 3 10 Parm === 3 [[ 185 83 664 94 61 72 241 313 649 654 662 562 569 575 582 ]] Parm0: long !jvms: TestUnsafeAllocateLongAdr::test @ bci:-1 (line 16) 3 650 LShiftL === _ 633 115 [[ 660 654 ]] 2 654 AddL === _ 650 10 [[ 655 ]] !orig=[651],[476],[454] 1 540 ConL === 0 [[ 470 564 ]] #long:40 1 655 CastX2P === _ 654 [[ 470 ]] 0 470 AddP === _ 1 655 540 [[ 469 ]] !orig=461,[143] !jvms: TestUnsafeAllocateLongAdr::test @ bci:23 (line 17) VPointer::init_is_valid: summand is not pre-loop invariant: 1 * [655 CastX2P] VPointer::VPointer: mem: 469 StoreL === 593 477 470 473 [[ 398 ]] @rawptr:BotPTR, idx=Raw; unaligned unsafe Memory: @rawptr:BotPTR, idx=Raw; !orig=146,416 !jvms: TestUnsafeAllocateLongAdr::test @ bci:23 (line 17) VPointer[invalid] MemPointerParser::parse: size=8 mem: 398 StoreL === 593 469 546 401 [[ 146 ]] @rawptr:BotPTR, idx=Raw; unaligned unsafe Memory: @rawptr:BotPTR, idx=Raw; !orig=146,416 !jvms: TestUnsafeAllocateLongAdr::test @ bci:23 (line 17) pointer: 546 AddP === _ 1 658 151 [[ 398 ]] !orig=[399],[143] !jvms: TestUnsafeAllocateLongAdr::test @ bci:23 (line 17) Raw Summands (2): <0: 48 * 1> + <0: 1 * 1 * [658 CastX2P]> Raw Summands (2): <0: 1 * 1 * [658 CastX2P]> + <0: 48 * 1> Summands (1): con(48) + 1 * [658 CastX2P] Summands (1): con(48) + 1 * [658 CastX2P] Hmm, I see. The issue is that we do not parse through CastX2P, unless we find "sub_expression_has_native_base_candidate". We don't have this issue with NativeMemory segments, because we should find the native base there. But here, with raw Unsafe allocated memory via a long ptr, we cannot do this. It may or may not be helpful to parse through a CastX2P, that depends on the exact case. However: in this case we know that the CastX2P is not pre-loop invariant, and so it would be smart to parse through in the hope of finding something invariant! But: This logic is in MemPointer, and we do not generally know about pre-loop invariance, MemPointer can also be used in other places. At any rate: as far as I know, this is a rare pattern, and one should probably use MemorySegment instead of Unsafe here anyway, and then this issue does not exist.
06-06-2025