mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-25 20:23:11 +01:00
1cc9a9a285
The current implementation of ThumbRegisterInfo::saveScavengerRegister is bad for two reasons: one, it's buggy, and two, it blocks using R12 for other optimizations. So this patch gets rid of it, and adds the necessary support for using an ordinary emergency spill slot on Thumb1. (Specifically, I think saveScavengerRegister was broken by r305625, and nobody noticed for two years because the codepath is almost never used. The new code will also probably not be used much, but it now has better tests, and if we fail to emit a necessary emergency spill slot we get a reasonable error message instead of a miscompile.) A rough outline of the changes in the patch: 1. Gets rid of ThumbRegisterInfo::saveScavengerRegister. 2. Modifies ARMFrameLowering::determineCalleeSaves to allocate an emergency spill slot for Thumb1. 3. Implements useFPForScavengingIndex, so the emergency spill slot isn't placed at a negative offset from FP on Thumb1. 4. Modifies the heuristics for allocating an emergency spill slot to support Thumb1. This includes fixing ExtraCSSpill so we don't try to use "lr" as a substitute for allocating an emergency spill slot. 5. Allocates a base pointer in more cases, so the emergency spill slot is always accessible. 6. Modifies ARMFrameLowering::ResolveFrameIndexReference to compute the right offset in the new cases where we're forcing a base pointer. 7. Ensures we never generate a load or store with an offset outside of its frame object. This makes the heuristics more straightforward. 8. Changes Thumb1 prologue and epilogue emission so it never uses register scavenging. Some of the changes to the emergency spill slot heuristics in determineCalleeSaves affect ARM/Thumb2; hopefully, they should allow the compiler to avoid allocating an emergency spill slot in cases where it isn't necessary. The rest of the changes should only affect Thumb1. Differential Revision: https://reviews.llvm.org/D63677 llvm-svn: 364490
37 lines
1.1 KiB
LLVM
37 lines
1.1 KiB
LLVM
; RUN: llc -mtriple=thumbv7-linux-gnueabi -o - %s | FileCheck %s
|
|
|
|
; This alloca is just large enough that FrameLowering decides it needs a frame
|
|
; to guarantee access, based on the range of ldrex.
|
|
|
|
; The actual alloca size is a bit of black magic, unfortunately: the real
|
|
; maximum accessible is 1020, but FrameLowering adds 16 bytes to its estimated
|
|
; stack size just because so the alloca is not actually the what the limit gets
|
|
; compared to. The important point is that we don't go up to ~4096, which is the
|
|
; default with no strange instructions.
|
|
define void @test_large_frame() {
|
|
; CHECK-LABEL: test_large_frame:
|
|
; CHECK: push
|
|
; CHECK: sub.w sp, sp, #1008
|
|
|
|
%ptr = alloca i32, i32 252
|
|
|
|
%addr = getelementptr i32, i32* %ptr, i32 1
|
|
call i32 @llvm.arm.ldrex.p0i32(i32* %addr)
|
|
ret void
|
|
}
|
|
|
|
; This alloca is just is just the other side of the limit, so no frame
|
|
define void @test_small_frame() {
|
|
; CHECK-LABEL: test_small_frame:
|
|
; CHECK-NOT: push
|
|
; CHECK: sub.w sp, sp, #1004
|
|
|
|
%ptr = alloca i32, i32 251
|
|
|
|
%addr = getelementptr i32, i32* %ptr, i32 1
|
|
call i32 @llvm.arm.ldrex.p0i32(i32* %addr)
|
|
ret void
|
|
}
|
|
|
|
declare i32 @llvm.arm.ldrex.p0i32(i32*)
|