RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-01 00:12:50 +01:00
Code Issues Projects Releases Wiki Activity
d25c68a628
llvm-mirror/test/CodeGen/PowerPC/2010-02-12-saveCR.ll

31 lines
1.0 KiB
LLVM
Raw Normal View History

specify cpu for test to fix failure on some darwin systems with a g4+ cpu llvm-svn: 145699
2011-12-02 20:38:17 +01: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. llvm-svn: 96015
2010-02-12 22:35:34 +01: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:
enable PPC register scavenging by default (update tests and remove some FIXMEs) llvm-svn: 145819
2011-12-05 18:55:17 +01:00
;CHECK: lis r4, 1
;CHECK: ori r4, r4, 34524
;CHECK: mfcr r3
;CHECK: rlwinm r3, r3, 8, 0, 31
;CHECK: stwx r3, r1, r4
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. llvm-svn: 96015
2010-02-12 22:35:34 +01: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
call void asm sideeffect "", "~{cr2}"() nounwind
br label %return
return: ; preds = %entry
enable PPC register scavenging by default (update tests and remove some FIXMEs) llvm-svn: 145819
2011-12-05 18:55:17 +01:00
;CHECK: lis r3, 1
;CHECK: ori r3, r3, 34524
delaying restore-cr changed assigned registers in some tests llvm-svn: 145963
2011-12-06 21:55:46 +01:00
;CHECK: lwzx r3, r1, r3
;CHECK: rlwinm r3, r3, 24, 0, 31
;CHECK: mtcrf 32, r3
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. llvm-svn: 96015
2010-02-12 22:35:34 +01:00
ret void
}
declare void @bar(i8*)
Reference in New Issue Copy Permalink