[aarch64-port-dev ] RFR(L) Take 2 of Valhalla support for AArch64

[Andrew Haley]

On 3/27/19 3:14 PM, Dmitry Samersoff wrote:
> Please, review the next version of the changes against lworld branch:
> 
> http://cr.openjdk.java.net/~dsamersoff/valhalla_lworld_aarch64/webrev.04

+  ins_encode %{
+    if ($dst$$reg != $src$$reg) {
+      __ mov(as_Register($dst$$reg), as_Register($src$$reg));
+    }
+  %}

MacroAssembler::mov() doesn't generate any code if src == dst.

+        f.load_argument(1, r0); // rax,: array
+        f.load_argument(0, r1); // rbx,: index
+        int call_offset = __ call_RT(r0, noreg, CAST_FROM_FN_PTR(address, load_flattened_array), r0, r1);

rax? Are you sure about that? :-)

+void BarrierSetAssembler::nmethod_entry_barrier(MacroAssembler* masm)  {
+// DMS CHECK: 8210498: nmethod entry barriers, should we implement it?
+#if 0

I think you should decide what to do here.


+void MacroAssembler::test_field_is_flattenable(Register flags, Register temp_reg, Label& is_flattenable) {
+  (void) temp_reg; // keep signature uniform with x86
+  tbnz(flags, ConstantPoolCacheEntry::is_flattenable_field_shift, is_flattenable);
+}
+

Rather than casting to void, you can just say

 void MacroAssembler::test_field_is_flattenable(Register flags, Register, Label& is_flattenable) {

+  // Check if we need to extend the stack for unpacking
+  int sp_inc = (args_on_stack_cc - args_on_stack) * VMRegImpl::stack_slot_size;
+  if (sp_inc > 0) {
+    // Save the return address, adjust the stack (make sure it is properly
+    // 16-byte aligned) and copy the return address to the new top of the stack.
+    // pop(r13);
+    sp_inc = align_up(sp_inc, StackAlignmentInBytes);
+    // DMS CHECK: subptr(rsp, sp_inc);
+    sub(sp, sp, sp_inc);
+    // push(r13);
+  } else {
+    // The scalarized calling convention needs less stack space than the unscalarized one.
+    // No need to extend the stack, the caller will take care of these adjustments.
+    sp_inc = 0;

Comments in here seem wrong: you're  not saving the return address.

I haven't tested any of this, but it all looks basically OK. Good work.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671