[AIX] Enable frame pointer for AIX and add related test suite

[Xiangling_L]

Summary

This patch:

• enable frame pointer for AIX
• update some of red zone comments[we may need an extra NFC patch to address all red zone related comments]
• add testcases

[ZarkoCA]

llvm/lib/Target/PowerPC/PPCFrameLowering.cpp

63

The comment talks about the Darwin ABI but it looks that part of the code is removed. Should the comment be edited or am I misunderstanding?

llvm/lib/Target/PowerPC/PPCSubtarget.h

301

Can this be rewritten to:
On the AIX ABI, the scratch area is called the stack floor as opposed to the red zone. The stack floor is 220 bytes lower than the stack pointer in 32-bit mode and 288 bytes lower in 64-bit mode? Does this capture the same meaning?

llvm/test/CodeGen/PowerPC/Frames-alloca.ll

2

Is this testing the 64-bit ELFV1 ABI or the 64-bit ELFV2 ABI? Basically I'm asking whether this should be powerpc64le-unknown-linux-gnu or is this ok?

39

typo: should be referred, this happens in other test cases below

llvm/test/CodeGen/PowerPC/aix-frames-alloca-with-func-call.ll

47

Thanks for including this test in this form. We can update it once we enable this.

[Xiangling_L]

llvm/lib/Target/PowerPC/PPCFrameLowering.cpp

63

It is because we have the same logic for SVR4, AIX and Darwin, so I skip the isDarwinABI() check. Maybe I can adjust the structure of the comments like:

Darwin comments...;
SVR4 ABI/AIX ABI:...;

return STI.isPPC64() ? -8U : -4U;

Please let me know if you think it would help.

llvm/lib/Target/PowerPC/PPCSubtarget.h

301

Yes, I think so. I will adjust the comment based on your suggestion. Thanks.

llvm/test/CodeGen/PowerPC/Frames-alloca.ll

2

The default ABI for 64bit BE on Linux platform is ELFV1 ABI, the which AIX ABI is similar to. So it should be fine to leave it as it is.

39

Thanks. updated it.

llvm/test/CodeGen/PowerPC/aix-frames-alloca-with-func-call.ll

47

No problem.

[Xiangling_L]

Update comments and fix typo in the testcase;

[ZarkoCA]

llvm/test/CodeGen/PowerPC/Frames-alloca.ll

2

Thanks for the explanation.

39

Sorry, I wasn't clear the same typo happens in the other test case files and not only in this one. I've marked the typos I caught.

llvm/test/CodeGen/PowerPC/Frames-large.ll

26

s/referrd/referred/

llvm/test/CodeGen/PowerPC/aix-frames-alloc-char.ll

19

s/referrd/referred/

llvm/test/CodeGen/PowerPC/aix-frames-alloca-with-func-call.ll

20

s/referrd/referred/

27

Can the #0 be removed?

llvm/test/CodeGen/PowerPC/aix-frames-dyn-multi-alloc.ll

18

s/referrd/reffered/

llvm/test/CodeGen/PowerPC/aix-frames-small.ll

21

s/referrd/referred/

llvm/test/CodeGen/PowerPC/aix32-frames-stack-floor.ll

11

s/referrd/referred/

llvm/test/CodeGen/PowerPC/aix64-frames-stack-floor.ll

11

s/referrd/referred/

[ZarkoCA]

I think this patch is really close, just needs some typo fixes. I'm hesitant to approve since no one else has had a chance to look at it.

llvm/lib/Target/PowerPC/PPCFrameLowering.cpp

63

Yes, I think that's better thanks.

llvm/test/CodeGen/PowerPC/Frames-alloca.ll

37

I find the comments in the tests really helpful in understanding what is happening and what to expect in the assembly, thanks for including these.

llvm/test/CodeGen/PowerPC/aix32-frames-stack-floor.ll

2

Nit: can you combine this and aix43-frames-stack-floor.ll in one file?

[Xiangling_L]

llvm/test/CodeGen/PowerPC/Frames-alloca.ll

39

Thank you.

llvm/test/CodeGen/PowerPC/aix32-frames-stack-floor.ll

2

The testcase for 32bit and 64bit are different in terms of how much bytes allocated will pass the stack floor limit. So that's why I separate them out.

[Xiangling_L]

Fix typos

[cebowleratibm]

Preliminary comments. I still need to go through the test changes more thoroughly.

llvm/lib/Target/PowerPC/PPCFrameLowering.cpp

63

I think it's ok to start removing darwin logic. I think the comment block should be discarded.

llvm/lib/Target/PowerPC/PPCSubtarget.h

301

I think this comment is unnecessary because it does not add anything beyond what is readily discerned from the code. What is useful is how the stack floor / redzone is calculated.

307–314

Suggestion to pull the comments into the logic:

unsigned getRedZoneSize() const {
  if (isDarwinABI())
    return 224;
  if (isPPC64())
    // 288 bytes = 18*8 (FPRs) + 18*8 (GPRs, GPR13 reserved)
    return 288;
  // AIX PPC32: 220 bytes = 18*8 (FPRs) + 19*4 (GPRs)
  // PPC32 SVR4ABI has no redzone.
  return isAIXABI() ? 220 : 0;
}

llvm/test/CodeGen/PowerPC/Frames-alloca.ll

3

Why did you drop the -NOFP from the prefix? Is the output expected to be the same between default and -frame-pointer=all?

5

isn't this redudant to line 1?

llvm/test/CodeGen/PowerPC/aix64-frames-stack-floor.ll

2

Why isn't there a PPC32 variant of this test?

[Xiangling_L]

llvm/test/CodeGen/PowerPC/Frames-alloca.ll

3

1. Because -frame-pointer=all means disable frame pointer optimization elimination. I kinda feel NOFP here is misleading. And also it's not consistent with other LINUX frame pointer tests naming convention.

2. And yes, the output is expected to be same.

5

This is to check if the default and -frame-pointer=all behave the same, the answer of which is they should be in this case.

llvm/test/CodeGen/PowerPC/aix64-frames-stack-floor.ll

2

They are in another file named aix32-frames-stack-floor.ll.

[cebowleratibm]

llvm/test/CodeGen/PowerPC/Frames-alloca.ll

3

I'm confused. Because the llc default is opt enabled, I would expect frame pointer elimination to be enabled.

[Xiangling_L]

llvm/test/CodeGen/PowerPC/Frames-alloca.ll

3

Yes, the frame pointer elimination is enabled. But frame pointer elimination really means that only when frame pointer is not totally necessary, llc can do optimization and eliminate the frame pointer. In this testcase, because we have variable length argument n for alloca instruction, the frame pointer becomes necessary and also an efficient way to calculate the original SP value.

[Xiangling_L]

Address comments and update testcases.

[sfertile]

llvm/lib/Target/PowerPC/PPCFrameLowering.cpp

69

If its the first spill slot in the gpr save area for both ELF and XCOFF we should remove SVR4 ABI.

[Xiangling_L]

Fix the comment

[cebowleratibm]

Some early issues. I need more time to go through the AIX assembly in detail to ensure it's correct.

llvm/test/CodeGen/PowerPC/Frames-dyn-alloca-with-func-call.ll

7 ↗

(On Diff #240977)

There is trailing whitespace after the \ in the patch. 2 occurrences detected when I applied the patch.

13 ↗

(On Diff #240977)

I expect there is a dependency on D73209, which adds the stack arg work. Perhaps it's cleaner if we make this patch dependent on that so that we can avoid churn.

69 ↗

(On Diff #240977)

are these stwux deliberately omitting the operands?

llvm/test/CodeGen/PowerPC/Frames-dyn-alloca.ll

35 ↗

(On Diff #240977)

I find it useful to insert whitespace to line up the assembly text.

52 ↗

(On Diff #240977)

whitespace

70 ↗

(On Diff #240977)

whitespace

85 ↗

(On Diff #240977)

whitespace

[Xiangling_L]

llvm/test/CodeGen/PowerPC/Frames-dyn-alloca-with-func-call.ll

13 ↗

(On Diff #240977)

I think if we want this patch have a dependency on stack arg work depends on which patch is likely to land first? If D73209 is close to land, then I think it makes sense to have this dependency?

69 ↗

(On Diff #240977)

Yes, cuz the rest of stwux is doing almost the same thing to update the SP and store allocated area address. And I focus more on We actually have 9 instances of dynamic stack allocation, identified by the stdux used to update the back-chain link.

llvm/test/CodeGen/PowerPC/Frames-dyn-alloca.ll

35 ↗

(On Diff #240977)

Thanks for mentioning this, I will update it.

[sfertile]

llvm/test/CodeGen/PowerPC/Frames-dyn-alloca-with-func-call.ll

29 ↗

(On Diff #240977)

I have a couple questions about this test.

We actually have 9 instances of dynamic stack allocation, identified by the stdux used to update the back-chain link.

Why 9 allocas? What is that exercising that say 2 or maybe 3 allocas wouldn't? The way this is worded it might imply that 9 dynamic allocations in the IR *must* produce 9 stdux instructions. Is that intended?

Allocated area is 4 bytes aligned in the case of int.

Where do we verify the stack adjustments are 4 byte aligned? Would it be more appropriate to say 'is at least 4 byte aligned' instead?

llvm/test/CodeGen/PowerPC/Frames-large.ll

29

Does this test warrant such a detailed description? To me it seems obvious what we are testing: updating the stack frame when the adjustment is too large to be encoded in an immediate.

llvm/test/CodeGen/PowerPC/Frames-small.ll

30 ↗

(On Diff #240977)

Ditto on the description being much too verbose for the test.

llvm/test/CodeGen/PowerPC/aix-frames-stack-floor.ll

13 ↗

(On Diff #240977)

Ditt on on the description being overly verbose. This test is simple enough I think its completely self describing.

[Xiangling_L]

llvm/test/CodeGen/PowerPC/Frames-dyn-alloca-with-func-call.ll

29 ↗

(On Diff #240977)

1. Why 9 allocas?

Because we want to test when we pass more than 8 parameters to callee, how the stack pointer rather than frame pointer comes into play to save the 9th on the stack, which is parameter save area are referred by stack pointer with correct offset.

2.The way this is worded it might imply that 9 dynamic allocations in the IR *must* produce 9 stdux instructions. Is that intended?
Yes, it's intended.

3.Would it be more appropriate to say 'is at least 4 byte aligned' instead?
Yes, I agree, and I will update it.

llvm/test/CodeGen/PowerPC/Frames-large.ll

29

Thanks for mentioning this, one reason I added this verbose description is there are some disturbing instructions like subf, addic in the CHECK content. Those content is to add more integrity for the CHECK. But I would expect viewers to not focus too much on those by skimming through the description first.

Besides, I guess it depends on reviewers to think if this description is useful or not. AFAIK, @ZarkoCA and @cebowleratibm may prefer this.

Anyway, I will leave it open for a while to see if there is some other input. Personally, I think it does no harm to have this description.

[Xiangling_L]

Fix formatting issue of testcases

[sfertile]

Besides, I guess it depends on reviewers to think if this description is useful or not. AFAIK, @ZarkoCA and @cebowleratibm may prefer this.

I am not against them in general even though I let alot of feedback on why we should remove most of them :) .If you think they are useful I am willing to work with you to refine them into something we are both happy with. I think the same kind of goals we have when writing code comments apply to test comments:

• Anything that can reasonably be made self documenting should be.

• There shouldn't be any redundant comments.

• Any comments we do add need to be completely clear and accurate.

I think the 3rd point is already covered, Its 1 and 2 that I'm pushing for.

llvm/test/CodeGen/PowerPC/Frames-large.ll

29

Thanks for mentioning this, one reason I added this verbose description is there are some disturbing instructions like subf, addic in the CHECK content.

But the comment doesn't address that. For example if I look at the ELF 32-bit no-frame-pointer test, I see th e subf instruction but the test description doesn't help me understand why. Adding the CHECK for it makes it look like it is significant to the test as well, but as far as I can tell its completely redundant.

# Build up the stack frame adjustment in register $r0
        lis 0, -1
        ori 0, 0, 32752

# Allocate new stack frame.
        stwux 1, 1, 0

# Why do we have this instruction? It doesn't set any condition register bits, and the result is killed next instruction. The test description doesn't help me understand this.
        subf 0, 0, 1

# Spill $r31 so we can use it to restore the original stack pointer. If $r0 is available to spill to ... why not just use it as the scratch register though ...
        mr 0, 31

# Get original stack pointer value from the backchain.
        lwz 31, 0(1)

# Calculate the address of the stack allocated object. Why is it 20 bytes off the stack-pointer? I'm not very familiar with PPC32, this is soemthing I'd like commented becuase its non-obvious.
        addi 3, 1, 20

# deallocate stack frame.
        mr 1, 31

# Restore non-volatile register we clobbered.
        mr 31, 0

# Return, end of test.
        blr

31

I think you already did a good job of documenting this through your filecheck prefixes 'FP' vs 'NO-FP'.

33

I think instead of these 2 lines it would better to have white space before and after the add instruction that calculates the address of the allocated object. You could add a comment at that instruction if you want to draw extra attention but if I don't already know what that instructions importance is I don't think this comment helps.

36

There is useful information in here that I don't think we could 'self-document' as part of the test.

Only one instance of dynamic stack allocation in this case

Documented through the check prefixes in every test except PPC32-LINUX-NOFP becuase you check-next everything no other st[dw]ux could sneak in before the return.

identified by
; the stdux used to update the back-chain link when allocated frame is large
; that we can not address it by a 16-bit signed integer.

That stdux/stwux is the register + register equivalent form of the register + immediate stores we would normally use is helpful to the test. How it adjusts the stack pointer and maintains the backchain might be useful as well, and that the limit where we have to switch to r+r from r+imm is when it overflows a signed 16-bit value.

[cebowleratibm]

Only minor test questions / requests. The change looks ok. I think we should explain the stack adj differences with the XL compiler before committing, specifically: do we need to allocate the PSA for the current frame even if there are no calls?

llvm/test/CodeGen/PowerPC/Frames-dyn-alloca.ll

79 ↗

(On Diff #241739)

Why are we adding 32 to the r3 return reg?

llvm/test/CodeGen/PowerPC/Frames-small.ll

74 ↗

(On Diff #241739)

XL compiler stack bump was 448 for this case. I suspect they are allocating 32 bytes for the min PSA even though there are no calls.

llvm/test/CodeGen/PowerPC/aix-frames-stack-floor.ll

1 ↗

(On Diff #241739)

I like test consistency across the PPC subtargets. I'd like to see Linux 32/64 as part of this test for consistency and documenting the behaviour differences of the PPC subtargets. If it makes sense to have an AIX stack floor test, then it makes sense to have a Linux stack floor test, even if it's not part of the test suite yet.

[Xiangling_L]

Update the testcases to make the description of each less verbose;
Add some comments to make the offset clearer with which the address of allocated area is referred by stack pointer;

[Xiangling_L]

llvm/test/CodeGen/PowerPC/Frames-dyn-alloca.ll

79 ↗

(On Diff #241739)

32 is the linkage 16-byte aligned linkage area size since the linkage area is always at the top of the stack even after we alloca some space during runtime.

[Xiangling_L]

Update the testcase after putting arguments on stack patch land;

[sfertile]

LGTM.

llvm/lib/Target/PowerPC/PPCFrameLowering.cpp

 
 static unsigned computeTOCSaveOffset(const PPCSubtarget &STI) {
   if (STI.isAIXABI())
     return STI.isPPC64() ? 40 : 20;
   return STI.isELFv2ABI() ? 24 : 40;
 }
 
 static unsigned computeFramePointerSaveOffset(const PPCSubtarget &STI) {
   // For the Darwin ABI:
   // We cannot use the TOC save slot (offset +20) in the PowerPC linkage area
   // for saving the frame pointer (if needed.)  While the published ABI has
   // not used this slot since at least MacOSX 10.2, there is older code
   // around that does use it, and that needs to continue to work.
-  if (STI.isDarwinABI())
-    return STI.isPPC64() ? -8U : -4U;
 
-  // SVR4 ABI: First slot in the general register save area.
+  // First slot in the general register save area.
   return STI.isPPC64() ? -8U : -4U;
 }
 
 static unsigned computeLinkageSize(const PPCSubtarget &STI) {
   if ((STI.isDarwinABI() || STI.isAIXABI()) || STI.isPPC64())
     return (STI.isELFv2ABI() ? 4 : 6) * (STI.isPPC64() ? 8 : 4);
 
   // 32-bit SVR4 ABI:
PPCFrameLowering::restoreCalleeSavedRegisters(MachineBasicBlock &MBB,
   return true;
 }
 
 unsigned PPCFrameLowering::getTOCSaveOffset() const {
   return TOCSaveOffset;
 }
 
 unsigned PPCFrameLowering::getFramePointerSaveOffset() const {
-  if (Subtarget.isAIXABI())
-    report_fatal_error("FramePointer is not implemented on AIX yet.");
   return FramePointerSaveOffset;
 }
 
 unsigned PPCFrameLowering::getBasePointerSaveOffset() const {
   if (Subtarget.isAIXABI())
     report_fatal_error("BasePointer is not implemented on AIX yet.");
   return BasePointerSaveOffset;
 }
 
 bool PPCFrameLowering::enableShrinkWrapping(const MachineFunction &MF) const {
   if (MF.getInfo<PPCFunctionInfo>()->shrinkWrapDisabled())
     return false;
   return (MF.getSubtarget<PPCSubtarget>().isSVR4ABI() &&
           MF.getSubtarget<PPCSubtarget>().isPPC64());
 }

llvm/lib/Target/PowerPC/PPCSubtarget.h

public:
   bool isQPXStackUnaligned() const { return IsQPXStackUnaligned; }
   Align getPlatformStackAlignment() const {
     if ((hasQPX() || isBGQ()) && !isQPXStackUnaligned())
       return Align(32);
 
     return Align(16);
   }
 
-  // DarwinABI has a 224-byte red zone. PPC32 SVR4ABI(Non-DarwinABI) has no
-  // red zone and PPC64 SVR4ABI has a 288-byte red zone.
+  // 1) DarwinABI has a 224-byte red zone.
+  // 2) PPC32 SVR4ABI has no red zone and PPC64 SVR4ABI has a 288-byte red zone.
+  // 3) For AIX ABI, the scratch area is called the stack floor as opposed to
+  //    the red zone. The stack floor is at 220 bytes for 32-bit mode and 288
+  //    bytes for 64-bit mode lower than the stack pointer.
+  //    [32-bit mode]
+  //    220 bytes = 18*8 (FPRs) + 19*4 (GPRs)
+  //    [64-bit mode]
+  //    288 bytes = 18*8 (FPRs) + 18*8 (GPRs, GPR13 reserved)
   unsigned  getRedZoneSize() const {
-    return isDarwinABI() ? 224 : (isPPC64() ? 288 : 0);
+    if (isAIXABI())
+      return isPPC64() ? 288: 220;
+    if (isDarwinABI())
+      return 224;
+    if (isPPC64())
+      return 288;
+
+    return 0;
   }
 
   bool hasHTM() const { return HasHTM; }
   bool hasFloat128() const { return HasFloat128; }
   bool isISA3_0() const { return IsISA3_0; }
   bool useLongCalls() const { return UseLongCalls; }
   bool needsSwapsForVSXMemOps() const {
     return hasVSX() && isLittleEndian() && !hasP9Vector();

llvm/test/CodeGen/PowerPC/Frames-alloca.ll

-; RUN: llc < %s -mtriple=powerpc-unknown-linux-gnu | FileCheck %s -check-prefix=CHECK-PPC32
-; RUN: llc < %s -mtriple=powerpc64-unknown-linux-gnu | FileCheck %s -check-prefix=CHECK-PPC64
-; RUN: llc < %s -mtriple=powerpc-unknown-linux-gnu -frame-pointer=all | FileCheck %s -check-prefix=CHECK-PPC32-NOFP
-; RUN: llc < %s -mtriple=powerpc64-unknown-linux-gnu -frame-pointer=all | FileCheck %s -check-prefix=CHECK-PPC64-NOFP
-; RUN: llc < %s -mtriple=powerpc-unknown-linux-gnu | FileCheck %s -check-prefix=CHECK-PPC32
-
-; CHECK-PPC32: stwu 1, -32(1)
-; CHECK-PPC32: stw 31, 28(1)
-; CHECK-PPC32: lwz 31, 0(1)
-; CHECK-PPC32-NOFP: stwu 1, -32(1)
-; CHECK-PPC32-NOFP: stw 31, 28(1)
-; CHECK-PPC32-NOFP: lwz 31, 0(1)
-
-; CHECK-PPC64: std 31, -8(1)
-; CHECK-PPC64: stdu 1, -64(1)
-; CHECK-PPC64: ld 1, 0(1)
-; CHECK-PPC64: ld 31, -8(1)
-; CHECK-PPC64-NOFP: std 31, -8(1)
-; CHECK-PPC64-NOFP: stdu 1, -64(1)
-; CHECK-PPC64-NOFP: ld 1, 0(1)
-; CHECK-PPC64-NOFP: ld 31, -8(1)
+; RUN: llc < %s -mtriple=powerpc-unknown-linux-gnu | FileCheck %s -check-prefix=PPC32-LINUX
+; RUN: llc < %s -mtriple=powerpc64-unknown-linux-gnu | FileCheck %s -check-prefix=PPC64-LINUX
+; RUN: llc < %s -mtriple=powerpc-unknown-linux-gnu -frame-pointer=all | FileCheck %s -check-prefix=PPC32-LINUX
+; RUN: llc < %s -mtriple=powerpc64-unknown-linux-gnu -frame-pointer=all | FileCheck %s -check-prefix=PPC64-LINUX
+; RUN: llc < %s -mtriple=powerpc-unknown-linux-gnu | FileCheck %s -check-prefix=PPC32-LINUX
+
+; RUN: llc < %s -mcpu=pwr4 -mattr=-altivec -verify-machineinstrs \ 
+; RUN: -mtriple=powerpc-ibm-aix-xcoff | FileCheck %s -check-prefix=PPC32-AIX
+
+; RUN: llc < %s -mcpu=pwr4 -mattr=-altivec -verify-machineinstrs \
+; RUN: -mtriple=powerpc-ibm-aix-xcoff -frame-pointer=all | FileCheck %s \
+; RUN: -check-prefix=PPC32-AIX
+
+; RUN: llc < %s -mcpu=pwr4 -mattr=-altivec -verify-machineinstrs \ 
+; RUN: -mtriple=powerpc64-ibm-aix-xcoff | FileCheck %s -check-prefix=PPC64-AIX
+
+; RUN: llc < %s -mcpu=pwr4 -mattr=-altivec -verify-machineinstrs \
+; RUN: -mtriple=powerpc64-ibm-aix-xcoff -frame-pointer=all | FileCheck %s \
+; RUN: -check-prefix=PPC64-AIX
 
 define i32* @f1(i32 %n) nounwind {
-  %tmp = alloca i32, i32 %n    ; <i32*> [#uses=1]
-  ret i32* %tmp
+        %tmp = alloca i32, i32 %n               ; <i32*> [#uses=1]
+        ret i32* %tmp
 }
+
+; PPC32-LINUX-LABEL: f1
+; PPC32-LINUX: stwu 1, -32(1)
+; PPC32-LINUX: stw 31, 28(1)
+; PPC32-LINUX: lwz 31, 0(1)
+
+; PPC64-LINUX-LABEL: f1
+; PPC64-LINUX: std 31, -8(1)
+; PPC64-LINUX: stdu 1, -64(1)
+; PPC64-LINUX: ld 1, 0(1)
+; PPC64-LINUX: ld 31, -8(1)
+
+; Test verifies for AIX:
+; - Frame pointer register (r31) is saved/defined/restored.
+; - Allocated area is referrd by frame pointer with correct offset.
+; - Allocated area is 4 bytes aligned in the case of int.
+; - Only one instance of dynamic stack allocation in this case, identified by
+;   the stdux used to update the back-chain link.
+
+; PPC32-AIX-LABEL: f1
+; PPC32-AIX: stw 31, -4(1)
+; PPC32-AIX-NEXT: stwu 1, -48(1)
+; PPC32-AIX-NEXT: slwi 3, 3, 2
+; PPC32-AIX-NEXT: mr 31, 1
+; PPC32-AIX-NEXT: addi 3, 3, 15
+; PPC32-AIX-NEXT: addi 4, 31, 48
+; PPC32-AIX-NEXT: rlwinm 3, 3, 0, 0, 27
+; PPC32-AIX-NEXT: neg 3, 3
+; PPC32-AIX-NEXT: stwux 4, 1, 3
+; PPC32-AIX-NEXT: addi 3, 1, 32
+; PPC32-AIX-NEXT: lwz 1, 0(1)
+; PPC32-AIX-NEXT: lwz 31, -4(1)
+; PPC32-AIX-NEXT: blr
+
+; PPC64-AIX-LABEL: f1
+; PPC64-AIX: std 31, -8(1)
+; PPC64-AIX-NEXT: stdu 1, -64(1)
+; PPC64-AIX-NEXT: lis 4, 32767
+; PPC64-AIX-NEXT: rldic 3, 3, 2, 30
+; PPC64-AIX-NEXT: ori 4, 4, 65535
+; PPC64-AIX-NEXT: addi 3, 3, 15
+; PPC64-AIX-NEXT: sldi 4, 4, 4
+; PPC64-AIX-NEXT: mr 31, 1
+; PPC64-AIX-NEXT: and 3, 3, 4
+; PPC64-AIX-NEXT: addi 4, 31, 64
+; PPC64-AIX-NEXT: neg 3, 3
+; PPC64-AIX-NEXT: stdux 4, 1, 3
+; PPC64-AIX-NEXT: addi 3, 1, 48
+; PPC64-AIX-NEXT: ld 1, 0(1)
+; PPC64-AIX-NEXT: ld 31, -8(1)
+; PPC64-AIX-NEXT: blr

llvm/test/CodeGen/PowerPC/Frames-large.ll

-; RUN: llc -verify-machineinstrs < %s -mtriple=powerpc-unknown-linux-gnu | FileCheck %s -check-prefix=PPC32-NOFP
-; RUN: llc -verify-machineinstrs < %s -mtriple=powerpc-unknown-linux-gnu -frame-pointer=all | FileCheck %s -check-prefix=PPC32-FP
+; RUN: llc -verify-machineinstrs < %s -mtriple=powerpc-unknown-linux-gnu | FileCheck %s -check-prefix=PPC32-LINUX-NOFP
+; RUN: llc -verify-machineinstrs < %s -mtriple=powerpc-unknown-linux-gnu -frame-pointer=all | FileCheck %s -check-prefix=PPC32-LINUX-FP
 
-; RUN: llc -verify-machineinstrs < %s -mtriple=powerpc64-unknown-linux-gnu | FileCheck %s -check-prefix=PPC64-NOFP
-; RUN: llc -verify-machineinstrs < %s -mtriple=powerpc64-unknown-linux-gnu -frame-pointer=all | FileCheck %s -check-prefix=PPC64-FP
+; RUN: llc -verify-machineinstrs < %s -mtriple=powerpc64-unknown-linux-gnu | FileCheck %s -check-prefix=PPC64-LINUX-NOFP
+; RUN: llc -verify-machineinstrs < %s -mtriple=powerpc64-unknown-linux-gnu -frame-pointer=all | FileCheck %s -check-prefix=PPC64-LINUX-FP
+
+; RUN: llc -verify-machineinstrs < %s -mcpu=pwr4 -mattr=-altivec \
+; RUN: -mtriple=powerpc-ibm-aix-xcoff | FileCheck %s \
+; RUN: -check-prefix=PPC32-AIX-NOFP
+
+; RUN: llc -verify-machineinstrs < %s -mcpu=pwr4 -mattr=-altivec \
+; RUN: -mtriple=powerpc-ibm-aix-xcoff -frame-pointer=all | FileCheck %s \
+; RUN: -check-prefix=PPC32-AIX-FP
+
+; RUN: llc -verify-machineinstrs < %s -mcpu=pwr4 -mattr=-altivec \
+; RUN: -mtriple=powerpc64-ibm-aix-xcoff | FileCheck %s \
+; RUN: -check-prefix=PPC64-AIX-NOFP
+
+; RUN: llc -verify-machineinstrs < %s -mcpu=pwr4 -mattr=-altivec \
+; RUN: -mtriple=powerpc64-ibm-aix-xcoff -frame-pointer=all | FileCheck %s \
+; RUN: -check-prefix=PPC64-AIX-FP
+
+; Test verifies:
+; - Frame pointer register (r31) is saved/defined/restored when frame pointer
+;   elimination is disabled.
+; - Allocated area is referrd by stack pointer with correct offset.
+; - Allocated area is 4 bytes aligned in the case of int.
+; - Only one instance of dynamic stack allocation in this case, identified by
+;   the stdux used to update the back-chain link when allocated frame is large
+;   that we can not address it by a 16-bit signed integer.
 
 define i32* @f1() nounwind {
         %tmp = alloca i32, i32 8191             ; <i32*> [#uses=1]
         ret i32* %tmp
 }
 
-; PPC32-NOFP: f1:
-; PPC32-NOFP:   lis 0, -1
-; PPC32-NOFP:   ori 0, 0, 32752
-; PPC32-NOFP:   stwux 1, 1, 0
-; PPC32-NOFP-DAG:   addi 3, 1, 20
-; PPC32-NOFP-DAG:   lwz 31, 0(1)
-; PPC32-NOFP:   mr 1, 31
-; PPC32-NOFP:   mr 31, 0
-; PPC32-NOFP:   blr
-
-; PPC32-FP: lis 0, -1
-; PPC32-FP: ori 0, 0, 32752
-; PPC32-FP: stwux 1, 1, 0
-; PPC32-FP: subf 0, 0, 1
-; PPC32-FP: addic 0, 0, -4
-; PPC32-FP: stwx 31, 0, 0
-; PPC32-FP: mr 31, 1
-; PPC32-FP: addi 3, 31, 16
-; PPC32-FP: lwz 31, 0(1)
-; PPC32-FP: lwz 0, -4(31)
-; PPC32-FP: mr 1, 31
-; PPC32-FP: mr 31, 0
-; PPC32-FP: blr
-
-; PPC64-NOFP: f1:
-; PPC64-NOFP:   lis 0, -1
-; PPC64-NOFP:   ori 0, 0, 32720
-; PPC64-NOFP:   stdux 1, 1, 0
-; PPC64-NOFP:   addi 3, 1, 52
-; PPC64-NOFP:   ld 1, 0(1)
-; PPC64-NOFP:   blr
-
-; PPC64-FP: f1:
-; PPC64-FP: lis 0, -1
-; PPC64-FP: ori 0, 0, 32704
-; PPC64-FP: std 31, -8(1)
-; PPC64-FP: stdux 1, 1, 0
-; PPC64-FP: mr 31, 1
-; PPC64-FP: addi 3, 31, 60
-; PPC64-FP: ld 1, 0(1)
-; PPC64-FP: ld 31, -8(1)
-; PPC64-FP: blr
+; PPC32-LINUX-NOFP-LABEL: f1
+; PPC32-LINUX-NOFP: lis 0, -1
+; PPC32-LINUX-NOFP: ori 0, 0, 32752
+; PPC32-LINUX-NOFP: stwux 1, 1, 0
+; PPC32-LINUX-NOFP-DAG: addi 3, 1, 20
+; PPC32-LINUX-NOFP-DAG: lwz 31, 0(1)
+; PPC32-LINUX-NOFP: mr 1, 31
+; PPC32-LINUX-NOFP: mr 31, 0
+; PPC32-LINUX-NOFP: blr
+
+; PPC32-LINUX-FP-LABEL: f1
+; PPC32-LINUX-FP: lis 0, -1
+; PPC32-LINUX-FP: ori 0, 0, 32752
+; PPC32-LINUX-FP: stwux 1, 1, 0
+; PPC32-LINUX-FP: subf 0, 0, 1
+; PPC32-LINUX-FP: addic 0, 0, -4
+; PPC32-LINUX-FP: stwx 31, 0, 0
+; PPC32-LINUX-FP: mr 31, 1
+; PPC32-LINUX-FP: addi 3, 31, 16
+; PPC32-LINUX-FP: lwz 31, 0(1)
+; PPC32-LINUX-FP: lwz 0, -4(31)
+; PPC32-LINUX-FP: mr 1, 31
+; PPC32-LINUX-FP: mr 31, 0
+; PPC32-LINUX-FP: blr
+
+; PPC64-LINUX-NOFP-LABEL: f1:
+; PPC64-LINUX-NOFP: lis 0, -1
+; PPC64-LINUX-NOFP: ori 0, 0, 32720
+; PPC64-LINUX-NOFP: stdux 1, 1, 0
+; PPC64-LINUX-NOFP: addi 3, 1, 52
+; PPC64-LINUX-NOFP: ld 1, 0(1)
+; PPC64-LINUX-NOFP: blr
+
+; PPC64-LINUX-FP-LABEL: f1:
+; PPC64-LINUX-FP: lis 0, -1
+; PPC64-LINUX-FP: ori 0, 0, 32704
+; PPC64-LINUX-FP: std 31, -8(1)
+; PPC64-LINUX-FP: stdux 1, 1, 0
+; PPC64-LINUX-FP: mr 31, 1
+; PPC64-LINUX-FP: addi 3, 31, 60
+; PPC64-LINUX-FP: ld 1, 0(1)
+; PPC64-LINUX-FP: ld 31, -8(1)
+; PPC64-LINUX-FP: blr
+
+; PPC32-AIX-NOFP-LABEL: f1
+; PPC32-AIX-NOFP: lis 0, -1
+; PPC32-AIX-NOFP-NEXT: ori 0, 0, 32736
+; PPC32-AIX-NOFP-NEXT: stwux 1, 1, 0
+; PPC32-AIX-NOFP-NEXT: addi 3, 1, 36
+; PPC32-AIX-NOFP-NEXT: lwz 1, 0(1)
+; PPC32-AIX-NOFP-NEXT: blr
+
+; PPC32-AIX-FP-LABEL: f1
+; PPC32-AIX-FP: lis 0, -1
+; PPC32-AIX-FP-NEXT: stw 31, -4(1)
+; PPC32-AIX-FP-NEXT: ori 0, 0, 32736
+; PPC32-AIX-FP-NEXT: stwux 1, 1, 0
+; PPC32-AIX-FP-NEXT: mr 31, 1
+; PPC32-AIX-FP-NEXT: addi 3, 31, 32
+; PPC32-AIX-FP-NEXT: lwz 1, 0(1)
+; PPC32-AIX-FP-NEXT: lwz 31, -4(1)
+; PPC32-AIX-FP-NEXT: blr
+
+; PPC64-AIX-NOFP-LABEL: f1
+; PPC64-AIX-NOFP: lis 0, -1
+; PPC64-AIX-NOFP-NEXT: ori 0, 0, 32720
+; PPC64-AIX-NOFP-NEXT: stdux 1, 1, 0
+; PPC64-AIX-NOFP-NEXT: addi 3, 1, 52
+; PPC64-AIX-NOFP-NEXT: ld 1, 0(1)
+; PPC64-AIX-NOFP-NEXT: blr
+
+; PPC64-AIX-FP-LABEL: f1
+; PPC64-AIX-FP: lis 0, -1
+; PPC64-AIX-FP-NEXT: std 31, -8(1)
+; PPC64-AIX-FP-NEXT: ori 0, 0, 32704
+; PPC64-AIX-FP-NEXT: stdux 1, 1, 0
+; PPC64-AIX-FP-NEXT: mr 31, 1
+; PPC64-AIX-FP-NEXT: addi 3, 31, 60
+; PPC64-AIX-FP-NEXT: ld 1, 0(1)
+; PPC64-AIX-FP-NEXT: ld 31, -8(1)
+; PPC64-AIX-FP-NEXT: blr

llvm/test/CodeGen/PowerPC/aix-frames-alloc-char.ll

+; RUN: llc < %s -mcpu=pwr4 -mattr=-altivec -verify-machineinstrs \
+; RUN: -mtriple=powerpc-ibm-aix-xcoff | FileCheck %s -check-prefix=PPC32-NOFP
+
+; RUN: llc < %s -mcpu=pwr4 -mattr=-altivec -verify-machineinstrs \
+; RUN: -mtriple=powerpc-ibm-aix-xcoff -frame-pointer=all | FileCheck %s \
+; RUN: -check-prefix=PPC32-FP
+
+; RUN: llc < %s -mcpu=pwr4 -mattr=-altivec -verify-machineinstrs \
+; RUN: -mtriple=powerpc64-ibm-aix-xcoff | FileCheck %s -check-prefix=PPC64-NOFP
+
+; RUN: llc < %s -mcpu=pwr4 -mattr=-altivec -verify-machineinstrs \
+; RUN: -mtriple=powerpc64-ibm-aix-xcoff -frame-pointer=all | FileCheck %s \
+; RUN: -check-prefix=PPC64-FP
+
+; Test verifies:
+; - Frame pointer register (r31) is saved/defined/restored when frame pointer
+;   elimination is disabled.
+; - Allocated area is referrd by frame pointer with correct offset.
+; - Allocated area is 16 bytes aligned in the case of char.
+
+define i8* @alloc_char() {
+        %tmp = alloca i8, i32 395, align 16
+        ret i8* %tmp
+}
+
+; PPC32-NOFP-LABEL: alloc_char
+; PPC32-NOFP: stwu 1, -432(1)
+; PPC32-NOFP-NEXT: addi 3, 1, 32
+; PPC32-NOFP-NEXT: addi 1, 1, 432
+; PPC32-NOFP-NEXT: blr
+
+; PPC32-FP-LABEL: alloc_char
+; PPC32-FP: stw 31, -4(1)
+; PPC32-FP-NEXT: stwu 1, -432(1)
+; PPC32-FP-NEXT: mr 31, 1
+; PPC32-FP-NEXT: addi 3, 31, 32
+; PPC32-FP-NEXT: addi 1, 1, 432
+; PPC32-FP-NEXT: lwz 31, -4(1)
+; PPC32-FP-NEXT: blr
+
+; PPC64-NOFP-LABEL: alloc_char
+; PPC64-NOFP: stdu 1, -448(1)
+; PPC64-NOFP-NEXT: addi 3, 1, 48
+; PPC64-NOFP-NEXT: addi 1, 1, 448
+; PPC64-NOFP-NEXT: blr
+
+; PPC64-FP-LABEL: alloc_char
+; PPC64-FP: std 31, -8(1)
+; PPC64-FP-NEXT: stdu 1, -464(1)
+; PPC64-FP-NEXT: mr 31, 1
+; PPC64-FP-NEXT: addi 3, 31, 48
+; PPC64-FP-NEXT: addi 1, 1, 464
+; PPC64-FP-NEXT: ld 31, -8(1)
+; PPC64-FP-NEXT: blr

llvm/test/CodeGen/PowerPC/aix-frames-alloca-with-func-call.ll

+; RUN: not llc -verify-machineinstrs < %s -mcpu=pwr4 -mattr=-altivec \
+; RUN: -mtriple=powerpc-ibm-aix-xcoff 2>&1 | FileCheck %s \
+; RUN: -check-prefix=CHECK
+
+; RUN: not llc -verify-machineinstrs < %s -mcpu=pwr4 -mattr=-altivec \
+; RUN: -mtriple=powerpc-ibm-aix-xcoff -frame-pointer=all 2>&1 | FileCheck %s \
+; RUN: -check-prefix=CHECK
+
+; RUN: not llc -verify-machineinstrs < %s -mcpu=pwr4 -mattr=-altivec \
+; RUN: -mtriple=powerpc64-ibm-aix-xcoff 2>&1 | FileCheck %s \
+; RUN: -check-prefix=CHECK
+
+; RUN: not llc -verify-machineinstrs < %s -mcpu=pwr4 -mattr=-altivec \
+; RUN: -mtriple=powerpc64-ibm-aix-xcoff -frame-pointer=all 2>&1 | FileCheck %s \
+; RUN: -check-prefix=CHECK
+
+; Test verifies:
+; - Frame pointer register (r31) is saved/defined/restored.
+; - Allocated area and parameter save area are referrd by stack pointer with
+;   correct offset, while local variable space is referred by frame pointer
+;   with correct offset.
+; - Allocated area is 4 bytes aligned in the case of int.
+; - We actually have 9 instances of dynamic stack allocation,
+;   identified by the stdux used to update the back-chain link.
+
+define dso_local signext i32 @foo(i32 %n) #0 {
+entry:
+  %ptr0 = alloca i32*
+  %0 = alloca i32, i32 %n
+  store i32* %0, i32** %ptr0
+  %1 = alloca i32, i32 %n
+  %2 = alloca i32, i32 %n
+  %3 = alloca i32, i32 %n
+  %4 = alloca i32, i32 %n
+  %5 = alloca i32, i32 %n
+  %6 = alloca i32, i32 %n
+  %7 = alloca i32, i32 %n
+  %8 = alloca i32, i32 %n
+  %9 = load i32*, i32** %ptr0
+
+  %call = call i32 @bar(i32* %1, i32* %2, i32* %3, i32* %4, i32* %5, i32* %6, i32* %7, i32* %8, i32* %9)
+  ret i32 %call
+}
+
+declare i32 @bar(i32*, i32*, i32*, i32*, i32*, i32*, i32*, i32*, i32*)
+
+CHECK: LLVM ERROR: Handling of placing parameters on the stack is unimplemented!

llvm/test/CodeGen/PowerPC/aix-frames-dyn-multi-alloc.ll

+; RUN: llc < %s -mcpu=pwr4 -mattr=-altivec -verify-machineinstrs \
+; RUN: -mtriple=powerpc-ibm-aix-xcoff | FileCheck %s -check-prefix=PPC32
+
+; RUN: llc < %s -mcpu=pwr4 -mattr=-altivec -verify-machineinstrs \
+; RUN: -mtriple=powerpc-ibm-aix-xcoff -frame-pointer=all | FileCheck %s \
+; RUN: -check-prefix=PPC32
+
+; RUN: llc < %s -mcpu=pwr4 -mattr=-altivec -verify-machineinstrs \
+; RUN: -mtriple=powerpc64-ibm-aix-xcoff | FileCheck %s -check-prefix=PPC64
+
+; RUN: llc < %s -mcpu=pwr4 -mattr=-altivec -verify-machineinstrs \
+; RUN: -mtriple=powerpc64-ibm-aix-xcoff -frame-pointer=all | FileCheck %s \
+; RUN: -check-prefix=PPC64
+
+; Test verifies:
+; - Frame pointer register (r31) is saved/defined/restored.
+; - Allocated area is referrd by stack pointer with correct offset.
+; - Allocated area is 4 bytes aligned in the case of int.
+; - We actually have two instances of dynamic stack allocation,
+;   identified by the stdux used to update the back-chain link.
+
+define void @test(i32 %n) {
+entry:
+  %0 = alloca i32, i32 %n
+  %1 = alloca i32, i32 %n
+  call void @use(i32* %0, i32* %1)
+  ret void
+}
+
+declare void @use(i32*, i32*)
+
+; PPC32-LABEL: test
+; PPC32: mflr 0
+; PPC32-NEXT: stw 31, -4(1)
+; PPC32-NEXT: stw 0, 8(1)
+; PPC32-NEXT: stwu 1, -80(1)
+; PPC32-NEXT: mr 31, 1
+; PPC32-NEXT: slwi 3, 3, 2
+; PPC32-NEXT: addi 3, 3, 15
+; PPC32-NEXT: rlwinm 3, 3, 0, 0, 27
+; PPC32-NEXT: neg 4, 3
+; PPC32-NEXT: addi 3, 31, 80
+; PPC32-NEXT: stwux 3, 1, 4
+; PPC32-NEXT: addi 5, 31, 80
+; PPC32-NEXT: addi 3, 1, 64
+; PPC32-NEXT: stwux 5, 1, 4
+; PPC32-NEXT: addi 4, 1, 64
+; PPC32-NEXT: bl .use
+; PPC32-NEXT: nop
+; PPC32-NEXT: lwz 1, 0(1)
+; PPC32-NEXT: lwz 0, 8(1)
+; PPC32-NEXT: mtlr 0
+; PPC32-NEXT: lwz 31, -4(1)
+; PPC32-NEXT: blr
+
+; PPC64-LABEL: test
+; PPC64: mflr 0
+; PPC64-NEXT: std 31, -8(1)
+; PPC64-NEXT: std 0, 16(1)
+; PPC64-NEXT: stdu 1, -128(1)
+; PPC64-NEXT: mr 31, 1
+; PPC64-NEXT: lis 4, 32767
+; PPC64-NEXT: rldic 3, 3, 2, 30
+; PPC64-NEXT: ori 4, 4, 65535
+; PPC64-NEXT: addi 3, 3, 15
+; PPC64-NEXT: sldi 4, 4, 4
+; PPC64-NEXT: and 3, 3, 4
+; PPC64-NEXT: neg 4, 3
+; PPC64-NEXT: addi 3, 31, 128
+; PPC64-NEXT: stdux 3, 1, 4
+; PPC64-NEXT: addi 5, 31, 128
+; PPC64-NEXT: addi 3, 1, 112
+; PPC64-NEXT: stdux 5, 1, 4
+; PPC64-NEXT: addi 4, 1, 112
+; PPC64-NEXT: bl .use
+; PPC64-NEXT: nop
+; PPC64-NEXT: ld 1, 0(1)
+; PPC64-NEXT: ld 0, 16(1)
+; PPC64-NEXT: mtlr 0
+; PPC64-NEXT: ld 31, -8(1)
+; PPC64-NEXT: blr

llvm/test/CodeGen/PowerPC/aix-frames-small.ll

+; RUN: llc -verify-machineinstrs < %s -mcpu=pwr4 -mattr=-altivec \
+; RUN: -mtriple=powerpc-ibm-aix-xcoff | FileCheck %s \
+; RUN: -check-prefix=PPC32-NOFP
+
+; RUN: llc -verify-machineinstrs < %s -mcpu=pwr4 -mattr=-altivec \
+; RUN: -mtriple=powerpc-ibm-aix-xcoff -frame-pointer=all | FileCheck %s \
+; RUN: -check-prefix=PPC32-FP
+
+; RUN: llc -verify-machineinstrs < %s -mcpu=pwr4 -mattr=-altivec \
+; RUN: -mtriple=powerpc64-ibm-aix-xcoff | FileCheck %s \
+; RUN: -check-prefix=PPC64-NOFP
+
+; RUN: llc -verify-machineinstrs < %s -mcpu=pwr4 -mattr=-altivec \
+; RUN: -mtriple=powerpc64-ibm-aix-xcoff -frame-pointer=all | FileCheck %s \
+; RUN: -check-prefix=PPC64-FP
+
+; Test verifies:
+; - Frame pointer register (r31) is saved/defined/restored when frame pointer
+;   elimination is disabled.
+; - Allocated area is referrd by stack pointer with correct offset.
+; - Allocated area is 4 bytes aligned in the case of int.
+; - Only one instance of dynamic stack allocation in this case, identified by
+;   the stdu used to update the back-chain link when allocated frame is small
+;   that we can address it by a 16-bit signed integer.
+
+define i32* @frame_small() {
+        %tmp = alloca i32, i32 95
+        ret i32* %tmp
+}
+
+; PPC32-NOFP-LABEL: frame_small
+; PPC32-NOFP: stwu 1, -416(1)
+; PPC32-NOFP-NEXT: addi 3, 1, 36
+; PPC32-NOFP-NEXT: addi 1, 1, 416
+; PPC32-NOFP-NEXT: blr
+
+; PPC32-FP-LABEL: frame_small
+; PPC32-FP: stw 31, -4(1)
+; PPC32-FP-NEXT: stwu 1, -416(1)
+; PPC32-FP-NEXT: mr 31, 1
+; PPC32-FP-NEXT: addi 3, 31, 32
+; PPC32-FP-NEXT: addi 1, 1, 416
+; PPC32-FP-NEXT: lwz 31, -4(1)
+; PPC32-FP-NEXT: blr
+
+; PPC64-NOFP-LABEL: frame_small
+; PPC64-NOFP: stdu 1, -432(1)
+; PPC64-NOFP-NEXT: addi 3, 1, 52
+; PPC64-NOFP-NEXT: addi 1, 1, 432
+; PPC64-NOFP-NEXT: blr
+
+; PPC64-FP-LABEL: frame_small
+; PPC64-FP: std 31, -8(1)
+; PPC64-FP-NEXT: stdu 1, -448(1)
+; PPC64-FP-NEXT: mr 31, 1
+; PPC64-FP-NEXT: addi 3, 31, 60
+; PPC64-FP-NEXT: addi 1, 1, 448
+; PPC64-FP-NEXT: ld 31, -8(1)
+; PPC64-FP-NEXT: blr

llvm/test/CodeGen/PowerPC/aix32-frames-stack-floor.ll

+; RUN: llc -verify-machineinstrs < %s -mcpu=pwr4 -mattr=-altivec \
+; RUN: -mtriple=powerpc-ibm-aix-xcoff | FileCheck %s -check-prefix=PPC32-NOFP
+
+; RUN: llc -verify-machineinstrs < %s -mcpu=pwr4 -mattr=-altivec \
+; RUN: -mtriple=powerpc-ibm-aix-xcoff -frame-pointer=all | FileCheck %s -check-prefix=PPC32-FP
+
+; Test verifies:
+; - Frame pointer register (r31) is saved/defined/restored when frame pointer
+;   elimination is disabled.
+; - Allocated area is referrd by stack pointer with correct offset.
+; - Allocated area is 4 bytes aligned in the case of int.
+; - On 32-bit AIX, a stackless leaf function does not acquire its own stack
+;   when the save area the function requires is less than 220 bytes.
+
+define i32* @in_stack_floor() {
+        %tmp = alloca i32, i32 55
+        ret i32* %tmp
+}
+
+define i32* @out_stack_floor() {
+        %tmp = alloca i32, i32 56
+        ret i32* %tmp
+}
+
+; PPC32-NOFP-LABEL: in_stack_floor
+; PPC32-NOFP: addi 3, 1, -220
+; PPC32-NOFP-NEXT: blr
+
+; PPC32-NOFP-LABEL: out_stack_floor
+; PPC32-NOFP: stwu 1, -256(1)
+; PPC32-NOFP-NEXT: addi 3, 1, 32
+; PPC32-NOFP-NEXT: addi 1, 1, 256
+; PPC32-NOFP-NEXT: blr
+
+; PPC32-FP-LABEL: in_stack_floor
+; PPC32-FP: stw 31, -4(1)
+; PPC32-FP-NEXT: stwu 1, -256(1)
+; PPC32-FP-NEXT: mr 31, 1
+; PPC32-FP-NEXT: addi 3, 31, 32
+; PPC32-FP-NEXT: addi 1, 1, 256
+; PPC32-FP-NEXT: lwz 31, -4(1)
+; PPC32-FP-NEXT: blr
+
+; PPC32-FP-LABEL: out_stack_floor
+; PPC32-FP: stw 31, -4(1)
+; PPC32-FP-NEXT: stwu 1, -256(1)
+; PPC32-FP-NEXT: mr 31, 1
+; PPC32-FP-NEXT: addi 3, 31, 28
+; PPC32-FP-NEXT: addi 1, 1, 256
+; PPC32-FP-NEXT: lwz 31, -4(1)
+; PPC32-FP-NEXT: blr

llvm/test/CodeGen/PowerPC/aix64-frames-stack-floor.ll

+; RUN: llc -verify-machineinstrs < %s -mcpu=pwr4 -mattr=-altivec \
+; RUN: -mtriple=powerpc64-ibm-aix-xcoff | FileCheck %s -check-prefix=PPC64-NOFP
+
+; RUN: llc -verify-machineinstrs < %s -mcpu=pwr4 -mattr=-altivec \
+; RUN: -mtriple=powerpc64-ibm-aix-xcoff -frame-pointer=all | FileCheck %s -check-prefix=PPC64-FP
+
+; Test verifies:
+; - Frame pointer register (r31) is saved/defined/restored when frame pointer
+;   elimination is disabled.
+; - Allocated area is referrd by stack pointer with correct offset.
+; - Allocated area is 4 bytes aligned in the case of int.
+; - On 64-bit AIX, a stackless leaf function does not acquire its own stack
+;   when the save area the function requires is less than 288 bytes.
+
+define i32* @in_stack_floor() {
+        %tmp = alloca i32, i32 72
+        ret i32* %tmp
+}
+
+define i32* @out_stack_floor() {
+        %tmp = alloca i32, i32 73
+        ret i32* %tmp
+}
+
+; PPC64-NOFP-LABEL: in_stack_floor
+; PPC64-NOFP: addi 3, 1, -288
+; PPC64-NOFP-NEXT: blr
+
+; PPC64-NOFP-LABEL: out_stack_floor
+; PPC64-NOFP: stdu 1, -352(1)
+; PPC64-NOFP-NEXT: addi 3, 1, 60
+; PPC64-NOFP-NEXT: addi 1, 1, 352
+; PPC64-NOFP-NEXT: blr
+
+; PPC64-FP-LABEL: in_stack_floor
+; PPC64-FP: std 31, -8(1)
+; PPC64-FP-NEXT: stdu 1, -352(1)
+; PPC64-FP-NEXT: mr 31, 1
+; PPC64-FP-NEXT: addi 3, 31, 56
+; PPC64-FP-NEXT: addi 1, 1, 352
+; PPC64-FP-NEXT: ld 31, -8(1)
+; PPC64-FP-NEXT: blr
+
+; PPC64-FP-LABEL: out_stack_floor
+; PPC64-FP: std 31, -8(1)
+; PPC64-FP-NEXT: stdu 1, -352(1)
+; PPC64-FP-NEXT: mr 31, 1
+; PPC64-FP-NEXT: addi 3, 31, 52
+; PPC64-FP-NEXT: addi 1, 1, 352
+; PPC64-FP-NEXT: ld 31, -8(1)
+; PPC64-FP-NEXT: blr