C1 for PPC64 contribution

[Christian Thalinger]

> On Oct 6, 2015, at 2:59 AM, Doerr, Martin <martin.doerr at sap.com> wrote:
> 
> Hi,
>  
> SAP has ported the C1 compiler to PPC64.  To contribute it, we require to do
> some minor shared changes to C1.  Some are bugfixes, others minor adaptions
> to support PPC64 specialities.  We will send out RFRs for the following changes
> step by step:
> http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete <http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete>
It’s unfortunate that the delete methods need to be public.  Why is that?

> http://cr.openjdk.java.net/~mdoerr/8138891_c1_cms_membar <http://cr.openjdk.java.net/~mdoerr/8138891_c1_cms_membar>
All the other architectures including AArch64 don’t need this and the implementation for membar_storestore is empty?

> http://cr.openjdk.java.net/~mdoerr/8138892_c1_counter_overflow <http://cr.openjdk.java.net/~mdoerr/8138892_c1_counter_overflow>
Can you give a little more context for this change?

> http://cr.openjdk.java.net/~mdoerr/8138894_c1_IRIW <http://cr.openjdk.java.net/~mdoerr/8138894_c1_IRIW>
That one looks ok.

> http://cr.openjdk.java.net/~mdoerr/8138895_c1_syncLockOpr <http://cr.openjdk.java.net/~mdoerr/8138895_c1_syncLockOpr>
Looks ok.

> http://cr.openjdk.java.net/~mdoerr/8138896_c1_patching_fix <http://cr.openjdk.java.net/~mdoerr/8138896_c1_patching_fix>
And you noticed this because the instruction size is different on PPC64?

> http://cr.openjdk.java.net/~mdoerr/8138952_c1_PPC64_defs <http://cr.openjdk.java.net/~mdoerr/8138952_c1_PPC64_defs>
   static int desired_max_code_buffer_size() {
-#ifndef PPC
-    return (int) NMethodSizeLimit;  // default 256K or 512K
+#if defined(PPC32)
+    return MIN2((size_t)NMethodSizeLimit, 32*K); // range of conditional branches
+#elif defined(PPC64)
+    return MIN2((size_t)NMethodSizeLimit, 32*M); // range of unconditional branches
 #else
-    // conditional branches on PPC are restricted to 16 bit signed
-    return MIN2((unsigned int)NMethodSizeLimit,32*K);
+    return (int) NMethodSizeLimit;  // default 256K or 512K
 #endif
   }

I wish this code be architecture dependent.  Wouldn’t it be better to limit the maximum NMethodSizeLimit via a command line flag constraint?

+#if defined(PPC64)
+  static LIR_Opr double_fpu(int reg)            { return (LIR_Opr)(intptr_t)((reg  << LIR_OprDesc::reg1_shift) |
+                                                                             (reg  << LIR_OprDesc::reg2_shift) |
+                                                                             LIR_OprDesc::double_type          |
+                                                                             LIR_OprDesc::fpu_register         |
+                                                                             LIR_OprDesc::double_size); }
+#endif
+#ifdef PPC32

   static LIR_Opr double_fpu(int reg)            { return (LIR_Opr)(intptr_t)((reg  << LIR_OprDesc::reg1_shift) |
                                                                              (reg  << LIR_OprDesc::reg2_shift) |
                                                                              LIR_OprDesc::double_type          |
                                                                              LIR_OprDesc::fpu_register         |
                                                                              LIR_OprDesc::double_size); }

What’s the difference between 32 and 64?  I don’t see it.

>  
> After this, we will contribute the changes to the ppc files in one blob.
>  
> We would appreciate your help in reviewing and especially sponsoring!
>  
> Best regards,
> Martin

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