[PPC][Hotspot] Aparently unrelated SharedRuntime::c_calling_convention call fails when implementing new intrinsics
Doerr, Martin
martin.doerr at sap.com
Mon Apr 10 14:22:08 UTC 2017
Hi Gustavo,
CCallingConventionRequiresIntsAsLongs is only true on PPC64 in jdk8u.
I think runtime.cpp would also need a change in OptoRuntime::multiplyToLen_Type():
if (CCallingConventionRequiresIntsAsLongs) {
fields[argp++] = TypePtr::NOTNULL; // x
fields[argp++] = TypeLong::LONG; // xlen
fields[argp++] = TypeLong::HALF; // placeholder
fields[argp++] = TypePtr::NOTNULL; // y
fields[argp++] = TypeLong::LONG; // ylen
fields[argp++] = TypeLong::HALF; // placeholder
fields[argp++] = TypePtr::NOTNULL; // z
fields[argp++] = TypeLong::LONG; // zlen
fields[argp++] = TypeLong::HALF; // placeholder
} else {
fields[argp++] = TypePtr::NOTNULL; // x
fields[argp++] = TypeInt::INT; // xlen
fields[argp++] = TypePtr::NOTNULL; // y
fields[argp++] = TypeInt::INT; // ylen
fields[argp++] = TypePtr::NOTNULL; // z
fields[argp++] = TypeInt::INT; // zlen
}
I'm not saying that I like this code, but that's how we had used it in 8.
Int to long conversion is needed as long as the stub call convention is not relaxed (as in jdk-8086069).
Best regards,
Martin
-----Original Message-----
From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br]
Sent: Montag, 10. April 2017 15:59
To: Doerr, Martin <martin.doerr at sap.com>; jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net
Subject: RE: [PPC][Hotspot] Aparently unrelated SharedRuntime::c_calling_convention call fails when implementing new intrinsics
Wait, there is still something missing I didn't understand: Why would then this kind of stub work on X64?
As I understood, I'd need to perform this change on hotspot/src/share/vm/opto/library_call.cpp , which is an arch-independent file. Wouldn't that be a drawback for other archs?
Thanks
> -----Original Message-----
> From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-
> bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet
> Sent: segunda-feira, 10 de abril de 2017 08:53
> To: Doerr, Martin <martin.doerr at sap.com>; jdk8u-dev at openjdk.java.net;
> ppc-aix-port-dev at openjdk.java.net
> Subject: RE: [PPC][Hotspot] Aparently unrelated
> SharedRuntime::c_calling_convention call fails when implementing new
> intrinsics
>
> Hello Martin,
>
> Thanks for explaining that! I'll perform these conversions on JDK8 and
> see how it goes.
>
> > -----Original Message-----
> > From: Doerr, Martin [mailto:martin.doerr at sap.com]
> > Sent: segunda-feira, 10 de abril de 2017 06:46
> > To: Gustavo Serra Scalet <gustavo.scalet at eldorado.org.br>; jdk8u-
> > dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net
> > Subject: RE: [PPC][Hotspot] Aparently unrelated
> > SharedRuntime::c_calling_convention call fails when implementing new
> > intrinsics
> >
> > 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