6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-12-24 22:32:47 +00:00
Code Issues Projects Releases Wiki Activity
4d53e7798c
llvm-6502/test/CodeGen/PowerPC/2010-02-12-saveCR.ll

37 lines
1.2 KiB
LLVM
Raw Normal View History

specify cpu for test to fix failure on some darwin systems with a g4+ cpu git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145699 91177308-0d34-0410-b5e6-96231b3b80d8
2011-12-02 19:38:17 +00:00
; RUN: llc < %s -mtriple=powerpc-apple-darwin -mcpu=g4 | FileCheck %s
When save/restoring CR at prolog/epilog, in a large stack frame, the prolog/epilog code was using the same register for the copy of CR and the address of the save slot. Oops. This is fixed here for Darwin, sort of, by reserving R2 for this case. A better way would be to do the store before the decrement of SP, which is safe on Darwin due to the red zone. SVR4 probably has the same problem, but I don't know how to fix it; there is no red zone and R2 is already used for something else. I'm going to leave it to someone interested in that target. Better still would be to rewrite the CR-saving code completely; spilling each CR subregister individually is horrible code. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96015 91177308-0d34-0410-b5e6-96231b3b80d8
2010-02-12 21:35:34 +00:00
; ModuleID = 'hh.c'
target datalayout = "E-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f128:64:128-n32"
target triple = "powerpc-apple-darwin9.6"
; This formerly used R0 for both the stack address and CR.
define void @foo() nounwind {
entry:
Don't reserve R2 on Darwin/PPC Now that only the register-scavenger version of the CR spilling code remains, we no longer need the Darwin R2 hack. Darwin can use R0 as a spare register in any case where the System V ABI uses it (R0 is special architecturally, and so is reserved under all common ABIs). A few test cases needed to be updated to reflect the register-allocation changes. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176868 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-12 15:18:14 +00:00
;CHECK: mfcr r0
;CHECK: lis r2, 1
;CHECK: rlwinm r0, r0, 8, 0, 31
;CHECK: ori r2, r2, 34524
;CHECK: stwx r0, r1, r2
Cleanup stack/frame register define/kill states. This fixes two bugs: 1. The ST*UX instructions that store and update the stack pointer did not set define/kill on R1. This became a problem when I activated post-RA scheduling (and had incorrectly adjusted the Frames-large test). 2. eliminateFrameIndex did not kill its scavenged temporary register, and this could cause the scavenger to exhaust all available registers (and its emergency spill slot) when there were a lot of CR values to spill. The 2010-02-12-saveCR test has been adjusted to check for this. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147359 91177308-0d34-0410-b5e6-96231b3b80d8
2011-12-30 00:34:00 +00:00
; Make sure that the register scavenger returns the same temporary register.
Don't reserve R2 on Darwin/PPC Now that only the register-scavenger version of the CR spilling code remains, we no longer need the Darwin R2 hack. Darwin can use R0 as a spare register in any case where the System V ABI uses it (R0 is special architecturally, and so is reserved under all common ABIs). A few test cases needed to be updated to reflect the register-allocation changes. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176868 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-12 15:18:14 +00:00
;CHECK: lis r2, 1
;CHECK: mfcr r0
;CHECK: ori r2, r2, 34520
;CHECK: rlwinm r0, r0, 12, 0, 31
;CHECK: stwx r0, r1, r2
When save/restoring CR at prolog/epilog, in a large stack frame, the prolog/epilog code was using the same register for the copy of CR and the address of the save slot. Oops. This is fixed here for Darwin, sort of, by reserving R2 for this case. A better way would be to do the store before the decrement of SP, which is safe on Darwin due to the red zone. SVR4 probably has the same problem, but I don't know how to fix it; there is no red zone and R2 is already used for something else. I'm going to leave it to someone interested in that target. Better still would be to rewrite the CR-saving code completely; spilling each CR subregister individually is horrible code. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96015 91177308-0d34-0410-b5e6-96231b3b80d8
2010-02-12 21:35:34 +00:00
%x = alloca [100000 x i8] ; <[100000 x i8]*> [#uses=1]
%"alloca point" = bitcast i32 0 to i32 ; <i32> [#uses=0]
%x1 = bitcast [100000 x i8]* %x to i8* ; <i8*> [#uses=1]
call void @bar(i8* %x1) nounwind
Cleanup stack/frame register define/kill states. This fixes two bugs: 1. The ST*UX instructions that store and update the stack pointer did not set define/kill on R1. This became a problem when I activated post-RA scheduling (and had incorrectly adjusted the Frames-large test). 2. eliminateFrameIndex did not kill its scavenged temporary register, and this could cause the scavenger to exhaust all available registers (and its emergency spill slot) when there were a lot of CR values to spill. The 2010-02-12-saveCR test has been adjusted to check for this. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147359 91177308-0d34-0410-b5e6-96231b3b80d8
2011-12-30 00:34:00 +00:00
call void asm sideeffect "", "~{cr2},~{cr3}"() nounwind
When save/restoring CR at prolog/epilog, in a large stack frame, the prolog/epilog code was using the same register for the copy of CR and the address of the save slot. Oops. This is fixed here for Darwin, sort of, by reserving R2 for this case. A better way would be to do the store before the decrement of SP, which is safe on Darwin due to the red zone. SVR4 probably has the same problem, but I don't know how to fix it; there is no red zone and R2 is already used for something else. I'm going to leave it to someone interested in that target. Better still would be to rewrite the CR-saving code completely; spilling each CR subregister individually is horrible code. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96015 91177308-0d34-0410-b5e6-96231b3b80d8
2010-02-12 21:35:34 +00:00
br label %return
return: ; preds = %entry
Don't reserve R2 on Darwin/PPC Now that only the register-scavenger version of the CR spilling code remains, we no longer need the Darwin R2 hack. Darwin can use R0 as a spare register in any case where the System V ABI uses it (R0 is special architecturally, and so is reserved under all common ABIs). A few test cases needed to be updated to reflect the register-allocation changes. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176868 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-12 15:18:14 +00:00
;CHECK: lis r2, 1
;CHECK: ori r2, r2, 34524
;CHECK: lwzx r0, r1, r2
;CHECK: rlwinm r0, r0, 24, 0, 31
;CHECK: mtcrf 32, r0
When save/restoring CR at prolog/epilog, in a large stack frame, the prolog/epilog code was using the same register for the copy of CR and the address of the save slot. Oops. This is fixed here for Darwin, sort of, by reserving R2 for this case. A better way would be to do the store before the decrement of SP, which is safe on Darwin due to the red zone. SVR4 probably has the same problem, but I don't know how to fix it; there is no red zone and R2 is already used for something else. I'm going to leave it to someone interested in that target. Better still would be to rewrite the CR-saving code completely; spilling each CR subregister individually is horrible code. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96015 91177308-0d34-0410-b5e6-96231b3b80d8
2010-02-12 21:35:34 +00:00
ret void
}
declare void @bar(i8*)
Reference in New Issue Copy Permalink