RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-25 04:02:41 +01:00
Code Issues Projects Releases Wiki Activity
55b3136c52
llvm-mirror/test/CodeGen/ARM/va_arg.ll

43 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 02:38:32 +02: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-26 20:22:20 +02:00
; Test that we correctly align elements when using va_arg
Convert CodeGen/*/*.ll tests to use the new CHECK-LABEL for easier debugging. No functionality change and all tests pass after conversion. This was done with the following sed invocation to catch label lines demarking function boundaries: sed -i '' "s/^;\( *\)\([A-Z0-9_]*\):\( *\)test\([A-Za-z0-9_-]*\):\( *\)$/;\1\2-LABEL:\3test\4:\5/g" test/CodeGen/*/*.ll which was written conservatively to avoid false positives rather than false negatives. I scanned through all the changes and everything looks correct. llvm-svn: 186258
2013-07-13 22:38:47 +02:00
; CHECK-LABEL: test1:
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 06:01:49 +02:00
; 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 02:38:32 +02:00
; CHECK: add [[REG:(r[0-9]+)|(lr)]], {{(r[0-9]+)|(lr)}}, #7
[ARM] Prefer BIC over BFC in ARM mode. BIC is generally faster, and it can put the output in a different register from the input. We already do this in Thumb2 mode; not sure why the equivalent fix never got applied to ARM mode. Differential Revision: https://reviews.llvm.org/D31797 llvm-svn: 299803
2017-04-08 00:01:23 +02:00
; CHECK: bic {{(r[0-9]+)|(lr)}}, [[REG]], #7
; CHECK-NOT: bic
When splitting a VAARG, remember its alignment. This produces terrible but correct code. llvm-svn: 106952
2010-06-26 20:22:20 +02: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 06:01:49 +02: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-26 20:22:20 +02: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
}
Convert CodeGen/*/*.ll tests to use the new CHECK-LABEL for easier debugging. No functionality change and all tests pass after conversion. This was done with the following sed invocation to catch label lines demarking function boundaries: sed -i '' "s/^;\( *\)\([A-Z0-9_]*\):\( *\)test\([A-Za-z0-9_-]*\):\( *\)$/;\1\2-LABEL:\3test\4:\5/g" test/CodeGen/*/*.ll which was written conservatively to avoid false positives rather than false negatives. I scanned through all the changes and everything looks correct. llvm-svn: 186258
2013-07-13 22:38:47 +02:00
; CHECK-LABEL: test2:
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 06:01:49 +02:00
; 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 02:38:32 +02:00
; CHECK: add [[REG:(r[0-9]+)|(lr)]], {{(r[0-9]+)|(lr)}}, #7
[ARM] Prefer BIC over BFC in ARM mode. BIC is generally faster, and it can put the output in a different register from the input. We already do this in Thumb2 mode; not sure why the equivalent fix never got applied to ARM mode. Differential Revision: https://reviews.llvm.org/D31797 llvm-svn: 299803
2017-04-08 00:01:23 +02:00
; CHECK: bic {{(r[0-9]+)|(lr)}}, [[REG]], #7
; CHECK-NOT: bic
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 06:01:49 +02:00
; CHECK: bx lr
AArch64 & ARM: remove undefined behaviour from some tests. llvm-svn: 209880
2014-05-30 10:59:55 +02:00
define double @test2(i32 %a, i32* %b, ...) nounwind optsize {
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 06:01:49 +02:00
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]
AArch64 & ARM: remove undefined behaviour from some tests. llvm-svn: 209880
2014-05-30 10:59:55 +02:00
store i32 %0, i32* %b
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 06:01:49 +02:00
%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-26 20:22:20 +02:00
declare void @llvm.va_start(i8*) nounwind
declare void @llvm.va_end(i8*) nounwind
Reference in New Issue Copy Permalink