maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/ARM/alloca-align.ll

25 lines
645 B
LLVM
Raw Normal View History

ARM: Compute MaxCallFrame size early This exposes a method in MachineFrameInfo that calculates MaxCallFrameSize and calls it after instruction selection in the ARM target. This avoids ARMBaseRegisterInfo::canRealignStack()/ARMFrameLowering::hasReservedCallFrame() giving different answers in early/late phases of codegen. The testcase shows a particular nasty example result of that where we would fail to properly align an alloca. Differential Revision: https://reviews.llvm.org/D32622 llvm-svn: 302303
2017-05-06 06:04:05 +08:00
; RUN: llc -o - %s | FileCheck %s
target triple="arm--"
@glob = external global i32*
declare void @bar(i32*, [20000 x i8]* byval)
; CHECK-LABEL: foo:
; We should see the stack getting additional alignment
; CHECK: sub sp, sp, #16
; CHECK: bic sp, sp, #31
; And a base pointer getting used.
; CHECK: mov r6, sp
; Which is passed to the call
RegScavenging: Add scavengeRegisterBackwards() Re-apply r276044/r279124/r305516. Fixed a problem where we would refuse to place spills as the very first instruciton of a basic block and thus artifically increase pressure (test in test/CodeGen/PowerPC/scavenging.mir:spill_at_begin) This is a variant of scavengeRegister() that works for enterBasicBlockEnd()/backward(). The benefit of the backward mode is that it is not affected by incomplete kill flags. This patch also changes PrologEpilogInserter::doScavengeFrameVirtualRegs() to use the register scavenger in backwards mode. Differential Revision: http://reviews.llvm.org/D21885 llvm-svn: 305625
2017-06-17 10:08:18 +08:00
; CHECK: add [[REG:r[0-9]+|lr]], r6, #19456
ARM: Compute MaxCallFrame size early This exposes a method in MachineFrameInfo that calculates MaxCallFrameSize and calls it after instruction selection in the ARM target. This avoids ARMBaseRegisterInfo::canRealignStack()/ARMFrameLowering::hasReservedCallFrame() giving different answers in early/late phases of codegen. The testcase shows a particular nasty example result of that where we would fail to properly align an alloca. Differential Revision: https://reviews.llvm.org/D32622 llvm-svn: 302303
2017-05-06 06:04:05 +08:00
; CHECK: add r0, [[REG]], #536
; CHECK: bl bar
define void @foo([20000 x i8]* %addr) {
%tmp = alloca [4 x i32], align 32
%tmp0 = getelementptr [4 x i32], [4 x i32]* %tmp, i32 0, i32 0
call void @bar(i32* %tmp0, [20000 x i8]* byval %addr)
ret void
}