[PPC][Hotspot] Aparently unrelated SharedRuntime::c_calling_convention call fails when implementing new intrinsics

Doerr, Martin martin.doerr at sap.com
Mon Apr 10 09:46:04 UTC 2017


Hi Gustavo,

before change "8086069: Adapt runtime calls to recent intrinsics to pass ints as long", it was required to convert int to long arguments for stub calls as well.

This could be done in library_call by:
    Node* call = NULL;
    if (CCallingConventionRequiresIntsAsLongs) {
      Node* xlen_I2L = ConvI2L(xlen);
      Node* ylen_I2L = ConvI2L(ylen);
      Node* zlen_I2L = ConvI2L(zlen);
      call = make_runtime_call(RC_LEAF|RC_NO_FP,
                               OptoRuntime::multiplyToLen_Type(),
                               stubAddr, stubName, TypePtr::BOTTOM,
                               x_start, xlen_I2L XTOP, y_start, ylen_I2L XTOP, z_start, zlen_I2L XTOP);
    }
    else {
      call = make_runtime_call(RC_LEAF|RC_NO_FP,
                               OptoRuntime::multiplyToLen_Type(),
                               stubAddr, stubName, TypePtr::BOTTOM,
                               x_start, xlen, y_start, ylen, z_start, zlen);
    }

In the current jdk9 code, stub calls are no longer performed according to the C calling convention (which requires int to long conversion on PPC64). The current stub code is designed to ignore the high 32 bits. Hence, the requirement for conversion only exists for real C calls, but no longer for stubs.

Best regards,
Martin


-----Original Message-----
From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet
Sent: Freitag, 7. April 2017 16:15
To: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net
Subject: [PPC][Hotspot] Aparently unrelated SharedRuntime::c_calling_convention call fails when implementing new intrinsics

Hi,

We implemented the MulAdd intrinsic on PPC on JDK 9 and now we're backporting it to 8 but I'm facing an exception which I assume it's a bug elsewhere:
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/sharedRuntime_ppc.cpp:737
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/gut/jdk8u-dev/hotspot/src/cpu/ppc/vm/sharedRuntime_ppc.cpp:737), pid=7631, tid=0x00003fff3454f1a0
#  guarantee(i > 0 && sig_bt[i-1] == T_LONG) failed: argument of type (bt) should have been promoted to type (T_LONG,bt) for bt in {T_BOOLEAN, T_CHAR, T_BYTE, T_SHORT, T_INT}
#
# JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-debug-gut_2017_04_05_11_00-b00)
# Java VM: OpenJDK 64-Bit Server VM (25.71-b00-debug mixed mode linux-ppc64 compressed oops)
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/gut/hs/hotspot/src/cpu/ppc/vm/tst/hs_err_pid7631.log
#
# Compiler replay data is saved as:
# /home/gut/hs/hotspot/src/cpu/ppc/vm/tst/replay_pid7631.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#
Current thread is 70365327192480
Dumping core ...
Aborted

Please take a look at the diff[1] for the new muladd and a test case[2] in java, which has an argument to repeat the main loop. Setting it with a high value such as 1234 is enough to jit the code and run the intrinsic.

I also noticed that this check in hotspot/src/cpu/ppc/vm/sharedRuntime_ppc.cpp does not exist in JDK9 due to a changeset[3] that was not backported. But that didn't stop X64 MulAdd intrinsics to work as it is. As I implemented one with the same interface, I don't understand why it's happening now...

Thanks in advance

[1] https://gist.github.com/gut/3d5f7984ef3114113b224853867bc906#file-add-muladd-ppc-diff
[2] https://gist.github.com/gut/3d5f7984ef3114113b224853867bc906#file-testmuladd-java
[3] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d7f63963925f#l3.7


More information about the ppc-aix-port-dev mailing list