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

Mon Apr 10 13:58:39 UTC 2017

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