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/va_arg.ll

42 lines
1.2 KiB
LLVM
Raw Normal View History

Recommit r129383. PreRA scheduler heuristic fixes: VRegCycle, TokenFactor latency. Additional fixes: Do something reasonable for subtargets with generic itineraries by handle node latency the same as for an empty itinerary. Now nodes default to unit latency unless an itinerary explicitly specifies a zero cycle stage or it is a TokenFactor chain. Original fixes: UnitsSharePred was a source of randomness in the scheduler: node priority depended on the queue data structure. I rewrote the recent VRegCycle heuristics to completely replace the old heuristic without any randomness. To make the ndoe latency adjustments work, I also needed to do something a little more reasonable with TokenFactor. I gave it zero latency to its consumers and always schedule it as low as possible. llvm-svn: 129421
2011-04-13 08:38:32 +08:00
; RUN: llc < %s -mtriple=armv7-none-linux-gnueabi -pre-RA-sched=source | FileCheck %s
When splitting a VAARG, remember its alignment. This produces terrible but correct code. llvm-svn: 106952
2010-06-27 02:22:20 +08:00
; Test that we correctly align elements when using va_arg
Fix va_arg for doubles. With this patch VAARG nodes always contain the correct alignment information, which simplifies ExpandRes_VAARG a bit. The patch introduces a new alignment information to TargetLoweringInfo. This is needed since the two natural candidates cannot be used: * The 's' in target data: If this is set to the minimal alignment of any argument, getCallFrameTypeAlignment would return 4 for doubles on ARM for example. * The getTransientStackAlignment method. It is possible for an architecture to have argument less aligned than what we maintain the stack pointer. llvm-svn: 108072
2010-07-11 12:01:49 +08:00
; CHECK: test1:
; CHECK-NOT: bfc
Recommit r129383. PreRA scheduler heuristic fixes: VRegCycle, TokenFactor latency. Additional fixes: Do something reasonable for subtargets with generic itineraries by handle node latency the same as for an empty itinerary. Now nodes default to unit latency unless an itinerary explicitly specifies a zero cycle stage or it is a TokenFactor chain. Original fixes: UnitsSharePred was a source of randomness in the scheduler: node priority depended on the queue data structure. I rewrote the recent VRegCycle heuristics to completely replace the old heuristic without any randomness. To make the ndoe latency adjustments work, I also needed to do something a little more reasonable with TokenFactor. I gave it zero latency to its consumers and always schedule it as low as possible. llvm-svn: 129421
2011-04-13 08:38:32 +08:00
; CHECK: add [[REG:(r[0-9]+)|(lr)]], {{(r[0-9]+)|(lr)}}, #7
; CHECK: bfc [[REG]], #0, #3
Fix va_arg for doubles. With this patch VAARG nodes always contain the correct alignment information, which simplifies ExpandRes_VAARG a bit. The patch introduces a new alignment information to TargetLoweringInfo. This is needed since the two natural candidates cannot be used: * The 's' in target data: If this is set to the minimal alignment of any argument, getCallFrameTypeAlignment would return 4 for doubles on ARM for example. * The getTransientStackAlignment method. It is possible for an architecture to have argument less aligned than what we maintain the stack pointer. llvm-svn: 108072
2010-07-11 12:01:49 +08:00
; CHECK-NOT: bfc
When splitting a VAARG, remember its alignment. This produces terrible but correct code. llvm-svn: 106952
2010-06-27 02:22:20 +08:00
Fix va_arg for doubles. With this patch VAARG nodes always contain the correct alignment information, which simplifies ExpandRes_VAARG a bit. The patch introduces a new alignment information to TargetLoweringInfo. This is needed since the two natural candidates cannot be used: * The 's' in target data: If this is set to the minimal alignment of any argument, getCallFrameTypeAlignment would return 4 for doubles on ARM for example. * The getTransientStackAlignment method. It is possible for an architecture to have argument less aligned than what we maintain the stack pointer. llvm-svn: 108072
2010-07-11 12:01:49 +08:00
define i64 @test1(i32 %i, ...) nounwind optsize {
When splitting a VAARG, remember its alignment. This produces terrible but correct code. llvm-svn: 106952
2010-06-27 02:22:20 +08:00
entry:
%g = alloca i8*, align 4
%g1 = bitcast i8** %g to i8*
call void @llvm.va_start(i8* %g1)
%0 = va_arg i8** %g, i64
call void @llvm.va_end(i8* %g1)
ret i64 %0
}
Fix va_arg for doubles. With this patch VAARG nodes always contain the correct alignment information, which simplifies ExpandRes_VAARG a bit. The patch introduces a new alignment information to TargetLoweringInfo. This is needed since the two natural candidates cannot be used: * The 's' in target data: If this is set to the minimal alignment of any argument, getCallFrameTypeAlignment would return 4 for doubles on ARM for example. * The getTransientStackAlignment method. It is possible for an architecture to have argument less aligned than what we maintain the stack pointer. llvm-svn: 108072
2010-07-11 12:01:49 +08:00
; CHECK: test2:
; CHECK-NOT: bfc
Recommit r129383. PreRA scheduler heuristic fixes: VRegCycle, TokenFactor latency. Additional fixes: Do something reasonable for subtargets with generic itineraries by handle node latency the same as for an empty itinerary. Now nodes default to unit latency unless an itinerary explicitly specifies a zero cycle stage or it is a TokenFactor chain. Original fixes: UnitsSharePred was a source of randomness in the scheduler: node priority depended on the queue data structure. I rewrote the recent VRegCycle heuristics to completely replace the old heuristic without any randomness. To make the ndoe latency adjustments work, I also needed to do something a little more reasonable with TokenFactor. I gave it zero latency to its consumers and always schedule it as low as possible. llvm-svn: 129421
2011-04-13 08:38:32 +08:00
; CHECK: add [[REG:(r[0-9]+)|(lr)]], {{(r[0-9]+)|(lr)}}, #7
; CHECK: bfc [[REG]], #0, #3
Fix va_arg for doubles. With this patch VAARG nodes always contain the correct alignment information, which simplifies ExpandRes_VAARG a bit. The patch introduces a new alignment information to TargetLoweringInfo. This is needed since the two natural candidates cannot be used: * The 's' in target data: If this is set to the minimal alignment of any argument, getCallFrameTypeAlignment would return 4 for doubles on ARM for example. * The getTransientStackAlignment method. It is possible for an architecture to have argument less aligned than what we maintain the stack pointer. llvm-svn: 108072
2010-07-11 12:01:49 +08:00
; CHECK-NOT: bfc
; CHECK: bx lr
define double @test2(i32 %a, i32 %b, ...) nounwind optsize {
entry:
%ap = alloca i8*, align 4 ; <i8**> [#uses=3]
%ap1 = bitcast i8** %ap to i8* ; <i8*> [#uses=2]
call void @llvm.va_start(i8* %ap1)
%0 = va_arg i8** %ap, i32 ; <i32> [#uses=0]
%1 = va_arg i8** %ap, double ; <double> [#uses=1]
call void @llvm.va_end(i8* %ap1)
ret double %1
}
When splitting a VAARG, remember its alignment. This produces terrible but correct code. llvm-svn: 106952
2010-06-27 02:22:20 +08:00
declare void @llvm.va_start(i8*) nounwind
declare void @llvm.va_end(i8*) nounwind