[PATCH] [mips] Add support for dynamic stack realignment.

[Daniel Sanders]

================
Comment at: lib/Target/Mips/MipsSERegisterInfo.cpp:142
@@ +141,3 @@
+    if (MFI->hasVarSizedObjects() && !MFI->isFixedObjectIndex(FrameIndex))
+      FrameReg = isN64 ? Mips::S7_64 : Mips::S7;
+    else if (FrameIndex < 0)
----------------
dsanders wrote:
> It's not necessary in this patch but we should consider adding inlined members to MipsRegisterInfo rather than duplicating the selection between REG and REG_64 all the time (e.g. getZeroReg(), getFPReg(), getSPReg(), etc.).
Most of this has been added to MipsABIInfo

================
Comment at: test/CodeGen/Mips/dynamic-stack-realignment.ll:22
@@ +21,3 @@
+  ; prologue
+  ; GP32:       addiu   $sp, $sp, -1024
+  ; GP32:       sw      $ra, 1020($sp)
----------------
dsanders wrote:
> I don't think -1024 is correct (but the program will work as far as I can tell). The frame will contain the 8-bytes for $ra/$fp, up to 504-bytes padding, 4-bytes for the alloca'd i32, 4-bytes for the 5th argument to helper_01, and 16-bytes for the reserved space, giving a total of between 32 and 536 bytes for the frame.
> 
> At the moment, we seem to be allocating 1024 bytes as well as up to 504 bytes padding. It looks like we're rounding the size of each region of the frame up to the maximum alignment.
> 
> We're discussing off-list whether the base pointer and locals with large alignments should be where they currently are. Some of the above issues may be related to the current position of this pointer and region.
We reached the conclusion that we can do better but it's not actually wrong. It's functional but not optimal. Given that the alignment of vectors isn't honoured at the moment (and this breaks pocl), we should proceed with this layout and refine it later.

================
Comment at: test/CodeGen/Mips/dynamic-stack-realignment.ll:233-259
@@ +232,28 @@
+
+; Check that we do not perform dynamic stack realignment in the presence of
+; the "no-realign-stack" function attribute.
+define void @func_09() "no-realign-stack" {
+entry:
+; ALL-LABEL: func_09:
+
+  ; ALL-NOT:  and     $sp, $sp, $[[T0:[0-9]+|ra|gp]]
+
+  %a = alloca i32, align 512
+  call void @helper_01(i32 0, i32 0, i32 0, i32 0, i32* %a)
+  ret void
+}
+
+define void @func_10(i32 %sz) "no-realign-stack" {
+entry:
+; ALL-LABEL: func_10:
+
+  ; ALL-NOT:  and     $sp, $sp, $[[T0:[0-9]+|ra|gp]]
+
+  %a0 = alloca i32, i32 %sz, align 512
+  %a1 = alloca i32, align 4
+
+  store volatile i32 111, i32* %a0, align 512
+  store volatile i32 222, i32* %a1, align 4
+
+  ret void
+}
----------------
Shouldn't these two cases be errors? We need to align to a large alignment but we can't because we've been told not to realign the stack.

http://reviews.llvm.org/D8633

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/