RFR: 8359235: C1 compilation fails with "assert(is_single_stack() && !is_virtual()) failed: type check"

[Guanqiang Han]

On Fri, 25 Jul 2025 21:11:45 GMT, Dean Long <dlong at openjdk.org> wrote:

>> @dean-long Thanks for the feedback!
>> Initially, I also considered modifying do_vectorizedMismatch() to use new_register(T_ADDRESS), as you suggested. However, I found that this change would trigger a series of follow-up modifications. as shown below:
>> <img width="847" height="179" alt="image3" src="https://github.com/user-attachments/assets/3dcbc5b7-5239-4154-a2f0-0c5f2d2ae5ac" />
>> <img width="783" height="190" alt="image4" src="https://github.com/user-attachments/assets/83fbce3f-9845-4ec1-a731-a1c6c88d1820" />
>> That’s why I opted for a more localized fix . I believe this is still a reasonable compromise. On 64-bit platforms, both T_ADDRESS and T_LONG are 64-bit wide, and general-purpose registers are capable of holding either type.  Moreover, the code already uses movptr for moving 64-bit wide data , as shown below:
>> <img width="1016" height="346" alt="image5" src="https://github.com/user-attachments/assets/fce9a083-aa4f-4d8b-a77f-9683d1f761b6" />
>> So semantically, this modification in PR seems safe and practical in this context.
>> That said, I fully agree that the current treatment of  new_pointer_register() is a bit confusing, If you, or other experts familiar with this area, believe the RFE is reasonable and it gets opened, I’d be happy to take on the implementation.
>> Thanks again for your insights, and I look forward to your feedback.
>
> @hgqxjj , I wasn't suggesting changing the new_pointer_register() implementation to use T_ADDRESS at this time, but to change intrinsics that call signature.append(T_ADDRESS) to use new_register(T_ADDRESS) for the register instead of with new_pointer_register().  As @TobiHartmann pointed out, we should fix all the intrinsics that are using signature.append(T_ADDRESS).

hi , @dean-long @TobiHartmann , i've updated the patch based on your feedback. Please take another look when you have time.

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

PR Comment: https://git.openjdk.org/jdk/pull/26462#issuecomment-3138299913