RFR(M): 8138952: C1: Distinguish between PPC32 and PPC64

Doerr, Martin martin.doerr at sap.com
Fri Nov 13 16:27:59 UTC 2015

Hi Christian,

thank you for reviewing.

Here my explanations for your 3 points (which I have marked in your mail):

I had made the change from #ifdef PPC to #if defined(PPC) intentionally, because we use the same code for other (not contributed) platforms as well and it’s easier to add platforms this way. Can you live with this as well? If not, I’ll remove it.

I think the #ifdef PPC64 for the TrapBasedNullChecks case is not so nice, but it does the right thing.
PPC64 is the only platform with doesn’t fully support signal-based null checks. The normal null_check should work fine for all other platforms. PPC64 (especially AIX, see 3.) needs a compare instruction if SIGTRAP is not used. In this case, the null check info needs to get passed.
The version of explicit_null_check which takes a register and the CodeEmitInfo is currently only implemented in our PPC64 code.
We could move it to shared code, but other platforms don’t need it at the moment.

TrapBasedNullChecks is a feature which is currently only implemented on PPC64. It enables the processor’s conditional trap instructions for null checks. It’s especially useful on AIX because the address 0 is readable (but not writeable) so we can’t use SEGV-based implicit null checks for loads.

Please let me know which changes to the webrev you would still like to see.

Best regards,

From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
Sent: Freitag, 13. November 2015 05:48
To: Doerr, Martin <martin.doerr at sap.com>
Cc: hotspot-compiler-dev at openjdk.java.net
Subject: Re: RFR(M): 8138952: C1: Distinguish between PPC32 and PPC64

I remember having looked at this before.


-#ifdef PPC
+#if defined(PPC)
-#endif // PPC
1. Please undo these changes.


     case lir_null_check:
       if (GenerateCompilerNullChecks) {
+#ifdef PPC64
+        if (!TrapBasedNullChecks) {
+          assert(op->in_opr()->is_single_cpu(), "expected");
+          explicit_null_check(op->in_opr()->as_register(), op->info());
+          break;
+        }

2. Do we really need the ifdef?  Shouldn’t the code work on other architectures too?  I see that TrapBasedNullChecks is false on all architectures except PPC:

src/closed/cpu/arm/vm/globals_arm.hpp:19:define_pd_global(bool,  TrapBasedNullChecks,      false); // Not needed
src/cpu/aarch64/vm/globals_aarch64.hpp:40:define_pd_global(bool, TrapBasedNullChecks,  false);
src/cpu/ppc/vm/globals_ppc.hpp:41:define_pd_global(bool, TrapBasedNullChecks,   true);
src/cpu/sparc/vm/globals_sparc.hpp:45:define_pd_global(bool, TrapBasedNullChecks,         false); // Not needed on sparc.
src/cpu/x86/vm/globals_x86.hpp:39:define_pd_global(bool, TrapBasedNullChecks,      false); // Not needed on x86.
src/cpu/zero/vm/globals_zero.hpp:40:define_pd_global(bool,  TrapBasedNullChecks,  false);

3. Shouldn’t all be true?

On Nov 12, 2015, at 12:07 AM, Doerr, Martin <martin.doerr at sap.com<mailto:martin.doerr at sap.com>> wrote:


we already have a local openjdk with C1 on PPC64. However, we can’t contribute it without these shared code changes.
This one should not change anything for PPC32 but change the defines as needed for PPC64.

Can someone review and sponsor, please?

Best regards,

From: Doerr, Martin
Sent: Dienstag, 3. November 2015 16:13
To: hotspot-compiler-dev at openjdk.java.net<mailto:hotspot-compiler-dev at openjdk.java.net>
Subject: RFR(M): 8138952: C1: Distinguish between PPC32 and PPC64


The shared C1 code currently uses many preprocessor directives which have been designed to work for the PPC32 port. In order to support our C1 port on PPC64 as well, some #ifdef etc. need modification.
Webrev is here:


PPC is defined if either PPC32 and PPC64 is defined so we use it for code which is used by both ports.
I made the following changes to webrev.00:
I changed c1_LIR.hpp to use PPC for the method defined twice.
I removed the modification of the defines in c1_Compilation.hpp (it’s not needed).

Please review this change.  I need a sponsor, please.

Best regards,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20151113/2470cb35/attachment-0001.html>

More information about the hotspot-compiler-dev mailing list