maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Transforms/ArgumentPromotion/byval.ll

51 lines
1.5 KiB
LLVM
Raw Normal View History

Convert some byval argpromotion grep tests to FileCheck Surprisingly, the i32* byval parameter is not transformed by argpromotion. llvm-svn: 212067
2014-07-01 04:44:28 +08:00
; RUN: opt < %s -argpromotion -S | FileCheck %s
[PM] Port ArgumentPromotion to the new pass manager. Now that the call graph supports efficient replacement of a function and spurious reference edges, we can port ArgumentPromotion to the new pass manager very easily. The old PM-specific bits are sunk into callbacks that the new PM simply doesn't use. Unlike the old PM, the new PM simply does argument promotion and afterward does the update to LCG reflecting the promoted function. Differential Revision: https://reviews.llvm.org/D29580 llvm-svn: 294667
2017-02-10 07:46:27 +08:00
; RUN: opt < %s -passes=argpromotion -S | FileCheck %s
Convert some byval argpromotion grep tests to FileCheck Surprisingly, the i32* byval parameter is not transformed by argpromotion. llvm-svn: 212067
2014-07-01 04:44:28 +08:00
Make opt default to not adding a target data string and update tests that depend on target data to supply it within the test llvm-svn: 85900
2009-11-03 23:29:06 +08:00
target datalayout = "E-p:64:64:64-a0:0:8-f32:32:32-f64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-v64:64:64-v128:128:128"
Teach argpromote to ruthlessly hack small byval structs when it can get away with it, which exposes opportunities to eliminate the memory objects entirely. For example, we now compile byval.ll to: define internal void @f1(i32 %b.0, i64 %b.1) { entry: %tmp2 = add i32 %b.0, 1 ; <i32> [#uses=0] ret void } define i32 @main() nounwind { entry: call void @f1( i32 1, i64 2 ) ret i32 0 } This seems like it would trigger a lot for code that passes around small structs (e.g. SDOperand's or _Complex)... llvm-svn: 45886
2008-01-12 06:31:41 +08:00
Convert some byval argpromotion grep tests to FileCheck Surprisingly, the i32* byval parameter is not transformed by argpromotion. llvm-svn: 212067
2014-07-01 04:44:28 +08:00
%struct.ss = type { i32, i64 }
Teach argpromote to ruthlessly hack small byval structs when it can get away with it, which exposes opportunities to eliminate the memory objects entirely. For example, we now compile byval.ll to: define internal void @f1(i32 %b.0, i64 %b.1) { entry: %tmp2 = add i32 %b.0, 1 ; <i32> [#uses=0] ret void } define i32 @main() nounwind { entry: call void @f1( i32 1, i64 2 ) ret i32 0 } This seems like it would trigger a lot for code that passes around small structs (e.g. SDOperand's or _Complex)... llvm-svn: 45886
2008-01-12 06:31:41 +08:00
define internal void @f(%struct.ss* byval %b) nounwind {
[ArgPromotion] Preserve alignment of byval argument in new alloca The frontend may have requested a higher alignment for any reason, and downstream optimizations may already have taken advantage of it. We should keep the same alignment when moving the allocation from the parameter area to the local variable area. Fixes PR34038 llvm-svn: 310071
2017-08-05 01:09:11 +08:00
entry:
%tmp = getelementptr %struct.ss, %struct.ss* %b, i32 0, i32 0
%tmp1 = load i32, i32* %tmp, align 4
%tmp2 = add i32 %tmp1, 1
store i32 %tmp2, i32* %tmp, align 4
ret void
}
Convert some byval argpromotion grep tests to FileCheck Surprisingly, the i32* byval parameter is not transformed by argpromotion. llvm-svn: 212067
2014-07-01 04:44:28 +08:00
; CHECK-LABEL: define internal void @f(i32 %b.0, i64 %b.1)
[ArgPromotion] Preserve alignment of byval argument in new alloca The frontend may have requested a higher alignment for any reason, and downstream optimizations may already have taken advantage of it. We should keep the same alignment when moving the allocation from the parameter area to the local variable area. Fixes PR34038 llvm-svn: 310071
2017-08-05 01:09:11 +08:00
; CHECK: alloca %struct.ss{{$}}
; CHECK: store i32 %b.0
; CHECK: store i64 %b.1
define internal void @g(%struct.ss* byval align 32 %b) nounwind {
Teach argpromote to ruthlessly hack small byval structs when it can get away with it, which exposes opportunities to eliminate the memory objects entirely. For example, we now compile byval.ll to: define internal void @f1(i32 %b.0, i64 %b.1) { entry: %tmp2 = add i32 %b.0, 1 ; <i32> [#uses=0] ret void } define i32 @main() nounwind { entry: call void @f1( i32 1, i64 2 ) ret i32 0 } This seems like it would trigger a lot for code that passes around small structs (e.g. SDOperand's or _Complex)... llvm-svn: 45886
2008-01-12 06:31:41 +08:00
entry:
[ArgPromotion] Preserve alignment of byval argument in new alloca The frontend may have requested a higher alignment for any reason, and downstream optimizations may already have taken advantage of it. We should keep the same alignment when moving the allocation from the parameter area to the local variable area. Fixes PR34038 llvm-svn: 310071
2017-08-05 01:09:11 +08:00
%tmp = getelementptr %struct.ss, %struct.ss* %b, i32 0, i32 0
%tmp1 = load i32, i32* %tmp, align 4
%tmp2 = add i32 %tmp1, 1
Convert some byval argpromotion grep tests to FileCheck Surprisingly, the i32* byval parameter is not transformed by argpromotion. llvm-svn: 212067
2014-07-01 04:44:28 +08:00
store i32 %tmp2, i32* %tmp, align 4
ret void
Teach argpromote to ruthlessly hack small byval structs when it can get away with it, which exposes opportunities to eliminate the memory objects entirely. For example, we now compile byval.ll to: define internal void @f1(i32 %b.0, i64 %b.1) { entry: %tmp2 = add i32 %b.0, 1 ; <i32> [#uses=0] ret void } define i32 @main() nounwind { entry: call void @f1( i32 1, i64 2 ) ret i32 0 } This seems like it would trigger a lot for code that passes around small structs (e.g. SDOperand's or _Complex)... llvm-svn: 45886
2008-01-12 06:31:41 +08:00
}
[ArgPromotion] Preserve alignment of byval argument in new alloca The frontend may have requested a higher alignment for any reason, and downstream optimizations may already have taken advantage of it. We should keep the same alignment when moving the allocation from the parameter area to the local variable area. Fixes PR34038 llvm-svn: 310071
2017-08-05 01:09:11 +08:00
; CHECK-LABEL: define internal void @g(i32 %b.0, i64 %b.1)
; CHECK: alloca %struct.ss, align 32
; CHECK: store i32 %b.0
; CHECK: store i64 %b.1
Teach argpromote to ruthlessly hack small byval structs when it can get away with it, which exposes opportunities to eliminate the memory objects entirely. For example, we now compile byval.ll to: define internal void @f1(i32 %b.0, i64 %b.1) { entry: %tmp2 = add i32 %b.0, 1 ; <i32> [#uses=0] ret void } define i32 @main() nounwind { entry: call void @f1( i32 1, i64 2 ) ret i32 0 } This seems like it would trigger a lot for code that passes around small structs (e.g. SDOperand's or _Complex)... llvm-svn: 45886
2008-01-12 06:31:41 +08:00
define i32 @main() nounwind {
entry:
[ArgPromotion] Preserve alignment of byval argument in new alloca The frontend may have requested a higher alignment for any reason, and downstream optimizations may already have taken advantage of it. We should keep the same alignment when moving the allocation from the parameter area to the local variable area. Fixes PR34038 llvm-svn: 310071
2017-08-05 01:09:11 +08:00
%S = alloca %struct.ss
%tmp1 = getelementptr %struct.ss, %struct.ss* %S, i32 0, i32 0
Convert some byval argpromotion grep tests to FileCheck Surprisingly, the i32* byval parameter is not transformed by argpromotion. llvm-svn: 212067
2014-07-01 04:44:28 +08:00
store i32 1, i32* %tmp1, align 8
[ArgPromotion] Preserve alignment of byval argument in new alloca The frontend may have requested a higher alignment for any reason, and downstream optimizations may already have taken advantage of it. We should keep the same alignment when moving the allocation from the parameter area to the local variable area. Fixes PR34038 llvm-svn: 310071
2017-08-05 01:09:11 +08:00
%tmp4 = getelementptr %struct.ss, %struct.ss* %S, i32 0, i32 1
Convert some byval argpromotion grep tests to FileCheck Surprisingly, the i32* byval parameter is not transformed by argpromotion. llvm-svn: 212067
2014-07-01 04:44:28 +08:00
store i64 2, i64* %tmp4, align 4
[ArgPromotion] Preserve alignment of byval argument in new alloca The frontend may have requested a higher alignment for any reason, and downstream optimizations may already have taken advantage of it. We should keep the same alignment when moving the allocation from the parameter area to the local variable area. Fixes PR34038 llvm-svn: 310071
2017-08-05 01:09:11 +08:00
call void @f(%struct.ss* byval %S) nounwind
call void @g(%struct.ss* byval %S) nounwind
Convert some byval argpromotion grep tests to FileCheck Surprisingly, the i32* byval parameter is not transformed by argpromotion. llvm-svn: 212067
2014-07-01 04:44:28 +08:00
ret i32 0
Teach argpromote to ruthlessly hack small byval structs when it can get away with it, which exposes opportunities to eliminate the memory objects entirely. For example, we now compile byval.ll to: define internal void @f1(i32 %b.0, i64 %b.1) { entry: %tmp2 = add i32 %b.0, 1 ; <i32> [#uses=0] ret void } define i32 @main() nounwind { entry: call void @f1( i32 1, i64 2 ) ret i32 0 } This seems like it would trigger a lot for code that passes around small structs (e.g. SDOperand's or _Complex)... llvm-svn: 45886
2008-01-12 06:31:41 +08:00
}
[ArgPromotion] Preserve alignment of byval argument in new alloca The frontend may have requested a higher alignment for any reason, and downstream optimizations may already have taken advantage of it. We should keep the same alignment when moving the allocation from the parameter area to the local variable area. Fixes PR34038 llvm-svn: 310071
2017-08-05 01:09:11 +08:00
; CHECK-LABEL: define i32 @main
; CHECK: call void @f(i32 %{{.*}}, i64 %{{.*}})
; CHECK: call void @g(i32 %{{.*}}, i64 %{{.*}})