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

[Guanqiang Han]

On Sun, 27 Jul 2025 15:56:25 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> Thanks for looking into this!
>> 
>> When I run your test with `java -Xcomp -XX:TieredStopAtLevel=1 -XX:C1MaxInlineSize=200 Test.java` we still crash when compiling `java.lang.invoke.LambdaFormEditor::putInCache` and if I restrict compilation to your test method via `-XX:CompileCommand=compileonly,Test::*`, the issue does not reproduce anymore. Could you please add a targeted regression test for this issue?
>
>> Thanks for looking into this!
>> 
>> When I run your test with `java -Xcomp -XX:TieredStopAtLevel=1 -XX:C1MaxInlineSize=200 Test.java` we still crash when compiling `java.lang.invoke.LambdaFormEditor::putInCache` and if I restrict compilation to your test method via `-XX:CompileCommand=compileonly,Test::*`, the issue does not reproduce anymore. Could you please add a targeted regression test for this issue?
> 
> @TobiHartmann Thanks for the feedback! I think there might be a bit of a misunderstanding.
> The original test program I provided is actually meant to reproduce the issue when run with: "java -Xcomp -XX:TieredStopAtLevel=1 -XX:C1MaxInlineSize=200 Test.java",it usually takes about 10 minutes to trigger the crash. Using -XX:CompileCommand=compileonly,Test::* won’t reproduce the issue because it compiles only a small subset of methods, which doesn’t put enough pressure on the register allocator to cause the spill (stack2reg can not be called ). Let’s forget about the previous test — I’ve redesigned a new one and already committed it. Feel free to give it a try when you have time!
> 
> 
> 
>> +1 to what Dean suggested. I think other intrinsics are affected by this as well though, for example:
>> 
>> https://github.com/openjdk/jdk/blob/b1fa1ecc988fb07f191892a459625c2c8f2de3b5/src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp#L953-L962
>> 
>> Also, what about other platforms than x86?
> 
> @TobiHartmann Other methods such as do_update_CRC32 may have similar issues, but they are harder to reproduce.  Fortunately, other architectures have not implemented do_vectorizedMismatch.

> @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).

@dean-long Thanks for your suggestion! After reviewing the code again, I think your approach would work fine for the x86 architecture. However, for other architectures like aarch64, we would also need to modify the implementation of leal accordingly, since it checks the type of the target operand. The relevant code is as follows:
https://github.com/openjdk/jdk/blob/4189fcbac40943f3b26c3a01938837b4e4762285/src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp#L985
https://github.com/openjdk/jdk/blob/4189fcbac40943f3b26c3a01938837b4e4762285/src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp#L2826
https://github.com/openjdk/jdk/blob/4189fcbac40943f3b26c3a01938837b4e4762285/src/hotspot/share/c1/c1_LIR.cpp#L40
https://github.com/openjdk/jdk/blob/4189fcbac40943f3b26c3a01938837b4e4762285/src/hotspot/share/c1/c1_LIR.hpp#L431
T_ADDRESS is not double cpu， so i need to modify the implementation of leal accordingly . @dean-long @TobiHartmann Do you think this approach is okay, or do you have any other suggestions?

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

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