6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-11-11 08:07:22 +00:00
Code Issues Projects Releases Wiki Activity
2e750c12e9
llvm-6502/test/CodeGen/Thumb2/2010-04-15-DynAllocBug.ll

19 lines
490 B
LLVM
Raw Normal View History

ARM SelectDYN_ALLOC should emit a copy from SP rather than referencing SP directly. In cases where there are two dyn_alloc in the same BB it would have caused the old SP value to be reused and badness ensues. rdar://7493908 llvm is generating poor code for dynamic alloca, I'll fix that later. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101383 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-15 18:42:28 +00:00
; RUN: llc < %s -mtriple=thumbv7-apple-darwin -mcpu=cortex-a8 -O3 | FileCheck %s
; rdar://7493908
; Make sure the result of the first dynamic_alloc isn't copied back to sp more
; than once. We'll deal with poor codegen later.
Remove arm_apcscc from the test files. It is the default and doing this matches what llvm-gcc and clang now produce. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@106221 91177308-0d34-0410-b5e6-96231b3b80d8
2010-06-17 15:18:27 +00:00
define void @t() nounwind ssp {
ARM SelectDYN_ALLOC should emit a copy from SP rather than referencing SP directly. In cases where there are two dyn_alloc in the same BB it would have caused the old SP value to be reused and badness ensues. rdar://7493908 llvm is generating poor code for dynamic alloca, I'll fix that later. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101383 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-15 18:42:28 +00:00
entry:
; CHECK: t:
Re-apply r112883: "For ARM stack frames that utilize variable sized objects and have either large local stack areas or require dynamic stack realignment, allocate a base register via which to access the local frame. This allows efficient access to frame indices not accessible via the FP (either due to being out of range or due to dynamic realignment) or the SP (due to variable sized object allocation). In particular, this greatly improves efficiency of access to spill slots in Thumb functions which contain VLAs." r112986 fixed a latent bug exposed by the above. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112989 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-03 18:37:12 +00:00
%size = mul i32 8, 2
Many Thumb2 instructions can reference the full ARM register set (i.e., have 4 bits per register in the operand encoding), but have undefined behavior when the operand value is 13 or 15 (SP and PC, respectively). The trivial coalescer in linear scan sometimes will merge a copy from SP into a subsequent instruction which uses the copy, and if that instruction cannot legally reference SP, we get bad code such as: mls r0,r9,r0,sp instead of: mov r2, sp mls r0, r9, r0, r2 This patch adds a new register class for use by Thumb2 that excludes the problematic registers (SP and PC) and is used instead of GPR for those operands which cannot legally reference PC or SP. The trivial coalescer explicitly requires that the register class of the destination for the COPY instruction contain the source register for the COPY to be considered for coalescing. This prevents errant instructions like that above. PR7499 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109842 91177308-0d34-0410-b5e6-96231b3b80d8
2010-07-30 02:41:01 +00:00
; CHECK: subs r0, #16
; CHECK: mov sp, r0
Re-apply r112883: "For ARM stack frames that utilize variable sized objects and have either large local stack areas or require dynamic stack realignment, allocate a base register via which to access the local frame. This allows efficient access to frame indices not accessible via the FP (either due to being out of range or due to dynamic realignment) or the SP (due to variable sized object allocation). In particular, this greatly improves efficiency of access to spill slots in Thumb functions which contain VLAs." r112986 fixed a latent bug exposed by the above. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112989 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-03 18:37:12 +00:00
%vla_a = alloca i8, i32 %size, align 8
Many Thumb2 instructions can reference the full ARM register set (i.e., have 4 bits per register in the operand encoding), but have undefined behavior when the operand value is 13 or 15 (SP and PC, respectively). The trivial coalescer in linear scan sometimes will merge a copy from SP into a subsequent instruction which uses the copy, and if that instruction cannot legally reference SP, we get bad code such as: mls r0,r9,r0,sp instead of: mov r2, sp mls r0, r9, r0, r2 This patch adds a new register class for use by Thumb2 that excludes the problematic registers (SP and PC) and is used instead of GPR for those operands which cannot legally reference PC or SP. The trivial coalescer explicitly requires that the register class of the destination for the COPY instruction contain the source register for the COPY to be considered for coalescing. This prevents errant instructions like that above. PR7499 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109842 91177308-0d34-0410-b5e6-96231b3b80d8
2010-07-30 02:41:01 +00:00
; CHECK: subs r0, #16
; CHECK: mov sp, r0
ARM SelectDYN_ALLOC should emit a copy from SP rather than referencing SP directly. In cases where there are two dyn_alloc in the same BB it would have caused the old SP value to be reused and badness ensues. rdar://7493908 llvm is generating poor code for dynamic alloca, I'll fix that later. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101383 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-15 18:42:28 +00:00
%vla_b = alloca i8, i32 %size, align 8
unreachable
}
Reference in New Issue Copy Permalink