[PPC][Hotspot] Aparently unrelated SharedRuntime::c_calling_convention call fails when implementing new intrinsics
Gustavo Serra Scalet
gustavo.scalet at eldorado.org.br
Mon Apr 10 19:47:18 UTC 2017
Hello Martin,
Just a short feedback: you got it all right! I could build the backport after changing what you pointed out and it's now working.
Thanks a lot once again.
> -----Original Message-----
> From: Doerr, Martin [mailto:martin.doerr at sap.com]
> Sent: segunda-feira, 10 de abril de 2017 11:22
> 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,
>
> 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 jdk8u-dev
mailing list