RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-01 08:23:21 +01:00
Code Issues Projects Releases Wiki Activity
742bb65cb8
llvm-mirror/test/Transforms/Inline/inline_cleanup.ll

214 lines
4.7 KiB
LLVM
Raw Normal View History

new testcase llvm-svn: 30302
2006-09-13 21:23:43 +02:00
; Test that the inliner doesn't leave around dead allocas, and that it folds
; uncond branches away after it is done specializing.
FileCheck-ize this test. Note the FIXME I've introduced here: we've regressed seriously here, we are no longer removing allocas during inline cleanup. This appears to be because of lifetime markers "using" them. =/ I'll look into this shortly. llvm-svn: 153394
2012-03-24 22:24:19 +01:00
; RUN: opt < %s -inline -S | FileCheck %s
Remove llvm-upgrade and update test cases. llvm-svn: 47793
2008-03-01 10:15:35 +01:00
@A = weak global i32 0 ; <i32*> [#uses=1]
@B = weak global i32 0 ; <i32*> [#uses=1]
@C = weak global i32 0 ; <i32*> [#uses=1]
new testcase llvm-svn: 30302
2006-09-13 21:23:43 +02:00
Remove llvm-upgrade and update test cases. llvm-svn: 47793
2008-03-01 10:15:35 +01:00
define internal fastcc void @foo(i32 %X) {
new testcase llvm-svn: 30302
2006-09-13 21:23:43 +02:00
entry:
Remove llvm-upgrade and update test cases. llvm-svn: 47793
2008-03-01 10:15:35 +01:00
%ALL = alloca i32, align 4 ; <i32*> [#uses=1]
%tmp1 = and i32 %X, 1 ; <i32> [#uses=1]
%tmp1.upgrd.1 = icmp eq i32 %tmp1, 0 ; <i1> [#uses=1]
br i1 %tmp1.upgrd.1, label %cond_next, label %cond_true
new testcase llvm-svn: 30302
2006-09-13 21:23:43 +02:00
cond_true: ; preds = %entry
Remove llvm-upgrade and update test cases. llvm-svn: 47793
2008-03-01 10:15:35 +01:00
store i32 1, i32* @A
new testcase llvm-svn: 30302
2006-09-13 21:23:43 +02:00
br label %cond_next
Remove llvm-upgrade and update test cases. llvm-svn: 47793
2008-03-01 10:15:35 +01:00
cond_next: ; preds = %cond_true, %entry
%tmp4 = and i32 %X, 2 ; <i32> [#uses=1]
%tmp4.upgrd.2 = icmp eq i32 %tmp4, 0 ; <i1> [#uses=1]
br i1 %tmp4.upgrd.2, label %cond_next7, label %cond_true5
new testcase llvm-svn: 30302
2006-09-13 21:23:43 +02:00
cond_true5: ; preds = %cond_next
Remove llvm-upgrade and update test cases. llvm-svn: 47793
2008-03-01 10:15:35 +01:00
store i32 1, i32* @B
new testcase llvm-svn: 30302
2006-09-13 21:23:43 +02:00
br label %cond_next7
Remove llvm-upgrade and update test cases. llvm-svn: 47793
2008-03-01 10:15:35 +01:00
cond_next7: ; preds = %cond_true5, %cond_next
%tmp10 = and i32 %X, 4 ; <i32> [#uses=1]
%tmp10.upgrd.3 = icmp eq i32 %tmp10, 0 ; <i1> [#uses=1]
br i1 %tmp10.upgrd.3, label %cond_next13, label %cond_true11
new testcase llvm-svn: 30302
2006-09-13 21:23:43 +02:00
cond_true11: ; preds = %cond_next7
Remove llvm-upgrade and update test cases. llvm-svn: 47793
2008-03-01 10:15:35 +01:00
store i32 1, i32* @C
new testcase llvm-svn: 30302
2006-09-13 21:23:43 +02:00
br label %cond_next13
Remove llvm-upgrade and update test cases. llvm-svn: 47793
2008-03-01 10:15:35 +01:00
cond_next13: ; preds = %cond_true11, %cond_next7
%tmp16 = and i32 %X, 8 ; <i32> [#uses=1]
%tmp16.upgrd.4 = icmp eq i32 %tmp16, 0 ; <i1> [#uses=1]
br i1 %tmp16.upgrd.4, label %UnifiedReturnBlock, label %cond_true17
new testcase llvm-svn: 30302
2006-09-13 21:23:43 +02:00
cond_true17: ; preds = %cond_next13
Remove llvm-upgrade and update test cases. llvm-svn: 47793
2008-03-01 10:15:35 +01:00
call void @ext( i32* %ALL )
new testcase llvm-svn: 30302
2006-09-13 21:23:43 +02:00
ret void
UnifiedReturnBlock: ; preds = %cond_next13
ret void
}
Remove llvm-upgrade and update test cases. llvm-svn: 47793
2008-03-01 10:15:35 +01:00
declare void @ext(i32*)
new testcase llvm-svn: 30302
2006-09-13 21:23:43 +02:00
Remove llvm-upgrade and update test cases. llvm-svn: 47793
2008-03-01 10:15:35 +01:00
define void @test() {
FileCheck-ize this test. Note the FIXME I've introduced here: we've regressed seriously here, we are no longer removing allocas during inline cleanup. This appears to be because of lifetime markers "using" them. =/ I'll look into this shortly. llvm-svn: 153394
2012-03-24 22:24:19 +01:00
; CHECK: @test
; CHECK-NOT: ret
;
; FIXME: This should be a CHECK-NOT, but currently we have a bug that causes us
; to not nuke unused allocas.
; CHECK: alloca
; CHECK-NOT: ret
;
; No branches should survive the inliner's cleanup.
; CHECK-NOT: br
; CHECK: ret void
new testcase llvm-svn: 30302
2006-09-13 21:23:43 +02:00
entry:
Remove llvm-upgrade and update test cases. llvm-svn: 47793
2008-03-01 10:15:35 +01:00
tail call fastcc void @foo( i32 1 )
tail call fastcc void @foo( i32 2 )
tail call fastcc void @foo( i32 3 )
tail call fastcc void @foo( i32 8 )
new testcase llvm-svn: 30302
2006-09-13 21:23:43 +02:00
ret void
}
Move the instruction simplification of callsite arguments in the inliner to instead rely on much more generic and powerful instruction simplification in the function cloner (and thus inliner). This teaches the pruning function cloner to use instsimplify rather than just the constant folder to fold values during cloning. This can simplify a large number of things that constant folding alone cannot begin to touch. For example, it will realize that 'or' and 'and' instructions with certain constant operands actually become constants regardless of what their other operand is. It also can thread back through the caller to perform simplifications that are only possible by looking up a few levels. In particular, GEPs and pointer testing tend to fold much more heavily with this change. This should (in some cases) have a positive impact on compile times with optimizations on because the inliner itself will simply avoid cloning a great deal of code. It already attempted to prune proven-dead code, but now it will be use the stronger simplifications to prove more code dead. llvm-svn: 153403
2012-03-25 06:03:40 +02:00
declare void @f(i32 %x)
Teach the function cloner (and thus the inliner) to simplify PHINodes aggressively. There are lots of dire warnings about this being expensive that seem to predate switching to the TrackingVH-based value remapper that is automatically updated on RAUW. This makes it easy to not just prune single-entry PHIs, but to fully simplify PHIs, and to recursively simplify the newly inlined code to propagate PHINode simplifications. This introduces a bit of a thorny problem though. We may end up simplifying a branch condition to a constant when we fold PHINodes, and we would like to nuke any dead blocks resulting from this so that time isn't wasted continually analyzing them, but this isn't easy. Deleting basic blocks *after* they are fully cloned and mapped into the new function currently requires manually updating the value map. The last piece of the simplification-during-inlining puzzle will require either switching to WeakVH mappings or some other piece of refactoring. I've left a FIXME in the testcase about this. llvm-svn: 153410
2012-03-25 12:34:54 +02:00
define void @inner2(i32 %x, i32 %y, i32 %z, i1 %b) {
Move the instruction simplification of callsite arguments in the inliner to instead rely on much more generic and powerful instruction simplification in the function cloner (and thus inliner). This teaches the pruning function cloner to use instsimplify rather than just the constant folder to fold values during cloning. This can simplify a large number of things that constant folding alone cannot begin to touch. For example, it will realize that 'or' and 'and' instructions with certain constant operands actually become constants regardless of what their other operand is. It also can thread back through the caller to perform simplifications that are only possible by looking up a few levels. In particular, GEPs and pointer testing tend to fold much more heavily with this change. This should (in some cases) have a positive impact on compile times with optimizations on because the inliner itself will simply avoid cloning a great deal of code. It already attempted to prune proven-dead code, but now it will be use the stronger simplifications to prove more code dead. llvm-svn: 153403
2012-03-25 06:03:40 +02:00
entry:
%cmp1 = icmp ne i32 %x, 0
br i1 %cmp1, label %then1, label %end1
then1:
call void @f(i32 %x)
br label %end1
end1:
%x2 = and i32 %x, %z
%cmp2 = icmp sgt i32 %x2, 1
br i1 %cmp2, label %then2, label %end2
then2:
call void @f(i32 %x2)
br label %end2
end2:
%y2 = or i32 %y, %z
%cmp3 = icmp sgt i32 %y2, 0
br i1 %cmp3, label %then3, label %end3
then3:
call void @f(i32 %y2)
br label %end3
end3:
Teach the function cloner (and thus the inliner) to simplify PHINodes aggressively. There are lots of dire warnings about this being expensive that seem to predate switching to the TrackingVH-based value remapper that is automatically updated on RAUW. This makes it easy to not just prune single-entry PHIs, but to fully simplify PHIs, and to recursively simplify the newly inlined code to propagate PHINode simplifications. This introduces a bit of a thorny problem though. We may end up simplifying a branch condition to a constant when we fold PHINodes, and we would like to nuke any dead blocks resulting from this so that time isn't wasted continually analyzing them, but this isn't easy. Deleting basic blocks *after* they are fully cloned and mapped into the new function currently requires manually updating the value map. The last piece of the simplification-during-inlining puzzle will require either switching to WeakVH mappings or some other piece of refactoring. I've left a FIXME in the testcase about this. llvm-svn: 153410
2012-03-25 12:34:54 +02:00
br i1 %b, label %end3.1, label %end3.2
end3.1:
%x3.1 = or i32 %x, 10
br label %end3.3
end3.2:
%x3.2 = or i32 %x, 10
br label %end3.3
end3.3:
%x3.3 = phi i32 [ %x3.1, %end3.1 ], [ %x3.2, %end3.2 ]
%cmp4 = icmp slt i32 %x3.3, 1
br i1 %cmp4, label %then4, label %end4
then4:
call void @f(i32 %x3.3)
br label %end4
end4:
Move the instruction simplification of callsite arguments in the inliner to instead rely on much more generic and powerful instruction simplification in the function cloner (and thus inliner). This teaches the pruning function cloner to use instsimplify rather than just the constant folder to fold values during cloning. This can simplify a large number of things that constant folding alone cannot begin to touch. For example, it will realize that 'or' and 'and' instructions with certain constant operands actually become constants regardless of what their other operand is. It also can thread back through the caller to perform simplifications that are only possible by looking up a few levels. In particular, GEPs and pointer testing tend to fold much more heavily with this change. This should (in some cases) have a positive impact on compile times with optimizations on because the inliner itself will simply avoid cloning a great deal of code. It already attempted to prune proven-dead code, but now it will be use the stronger simplifications to prove more code dead. llvm-svn: 153403
2012-03-25 06:03:40 +02:00
ret void
}
Teach the function cloner (and thus the inliner) to simplify PHINodes aggressively. There are lots of dire warnings about this being expensive that seem to predate switching to the TrackingVH-based value remapper that is automatically updated on RAUW. This makes it easy to not just prune single-entry PHIs, but to fully simplify PHIs, and to recursively simplify the newly inlined code to propagate PHINode simplifications. This introduces a bit of a thorny problem though. We may end up simplifying a branch condition to a constant when we fold PHINodes, and we would like to nuke any dead blocks resulting from this so that time isn't wasted continually analyzing them, but this isn't easy. Deleting basic blocks *after* they are fully cloned and mapped into the new function currently requires manually updating the value map. The last piece of the simplification-during-inlining puzzle will require either switching to WeakVH mappings or some other piece of refactoring. I've left a FIXME in the testcase about this. llvm-svn: 153410
2012-03-25 12:34:54 +02:00
define void @outer2(i32 %z, i1 %b) {
Move the instruction simplification of callsite arguments in the inliner to instead rely on much more generic and powerful instruction simplification in the function cloner (and thus inliner). This teaches the pruning function cloner to use instsimplify rather than just the constant folder to fold values during cloning. This can simplify a large number of things that constant folding alone cannot begin to touch. For example, it will realize that 'or' and 'and' instructions with certain constant operands actually become constants regardless of what their other operand is. It also can thread back through the caller to perform simplifications that are only possible by looking up a few levels. In particular, GEPs and pointer testing tend to fold much more heavily with this change. This should (in some cases) have a positive impact on compile times with optimizations on because the inliner itself will simply avoid cloning a great deal of code. It already attempted to prune proven-dead code, but now it will be use the stronger simplifications to prove more code dead. llvm-svn: 153403
2012-03-25 06:03:40 +02:00
; Ensure that after inlining, none of the blocks with a call to @f actually
; make it through inlining.
; CHECK: define void @outer2
; CHECK-NOT: call
; CHECK: ret void
entry:
Teach the function cloner (and thus the inliner) to simplify PHINodes aggressively. There are lots of dire warnings about this being expensive that seem to predate switching to the TrackingVH-based value remapper that is automatically updated on RAUW. This makes it easy to not just prune single-entry PHIs, but to fully simplify PHIs, and to recursively simplify the newly inlined code to propagate PHINode simplifications. This introduces a bit of a thorny problem though. We may end up simplifying a branch condition to a constant when we fold PHINodes, and we would like to nuke any dead blocks resulting from this so that time isn't wasted continually analyzing them, but this isn't easy. Deleting basic blocks *after* they are fully cloned and mapped into the new function currently requires manually updating the value map. The last piece of the simplification-during-inlining puzzle will require either switching to WeakVH mappings or some other piece of refactoring. I've left a FIXME in the testcase about this. llvm-svn: 153410
2012-03-25 12:34:54 +02:00
call void @inner2(i32 0, i32 -1, i32 %z, i1 %b)
Move the instruction simplification of callsite arguments in the inliner to instead rely on much more generic and powerful instruction simplification in the function cloner (and thus inliner). This teaches the pruning function cloner to use instsimplify rather than just the constant folder to fold values during cloning. This can simplify a large number of things that constant folding alone cannot begin to touch. For example, it will realize that 'or' and 'and' instructions with certain constant operands actually become constants regardless of what their other operand is. It also can thread back through the caller to perform simplifications that are only possible by looking up a few levels. In particular, GEPs and pointer testing tend to fold much more heavily with this change. This should (in some cases) have a positive impact on compile times with optimizations on because the inliner itself will simply avoid cloning a great deal of code. It already attempted to prune proven-dead code, but now it will be use the stronger simplifications to prove more code dead. llvm-svn: 153403
2012-03-25 06:03:40 +02:00
ret void
}
Sink the return instruction collection until after we're done deleting dead code, including dead return instructions in some cases. Otherwise, we end up having a bogus poniter to a return instruction that blows up much further down the road. It turns out that this pattern is both simpler to code, easier to update in the face of enhancements to the inliner cleanup, and likely cheaper given that it won't add dead instructions to the list. Thanks to John Regehr's numerous test cases for teasing this out. llvm-svn: 154157
2012-04-06 03:11:52 +02:00
define void @PR12470_inner(i16 signext %p1) nounwind uwtable {
entry:
br i1 undef, label %cond.true, label %cond.false
cond.true:
br label %cond.end
cond.false:
%conv = sext i16 %p1 to i32
br label %cond.end
cond.end:
%cond = phi i32 [ undef, %cond.true ], [ 0, %cond.false ]
%tobool = icmp eq i32 %cond, 0
br i1 %tobool, label %if.end5, label %if.then
if.then:
ret void
if.end5:
ret void
}
define void @PR12470_outer() {
; This previously crashed during inliner cleanup and folding inner return
; instructions. Check that we don't crash and we produce a function with a single
Actually finish this sentence in the comment the way I intended. Thanks Matt for pointing this out. llvm-svn: 154158
2012-04-06 03:19:38 +02:00
; return instruction due to merging the returns of the inlined function.
Sink the return instruction collection until after we're done deleting dead code, including dead return instructions in some cases. Otherwise, we end up having a bogus poniter to a return instruction that blows up much further down the road. It turns out that this pattern is both simpler to code, easier to update in the face of enhancements to the inliner cleanup, and likely cheaper given that it won't add dead instructions to the list. Thanks to John Regehr's numerous test cases for teasing this out. llvm-svn: 154157
2012-04-06 03:11:52 +02:00
; CHECK: define void @PR12470_outer
Tweak this test to ensure the inliner did indeed fire. Thanks to Richard Smith for pointing this out in review. llvm-svn: 154178
2012-04-06 19:21:28 +02:00
; CHECK-NOT: call
Sink the return instruction collection until after we're done deleting dead code, including dead return instructions in some cases. Otherwise, we end up having a bogus poniter to a return instruction that blows up much further down the road. It turns out that this pattern is both simpler to code, easier to update in the face of enhancements to the inliner cleanup, and likely cheaper given that it won't add dead instructions to the list. Thanks to John Regehr's numerous test cases for teasing this out. llvm-svn: 154157
2012-04-06 03:11:52 +02:00
; CHECK: ret void
; CHECK-NOT: ret void
; CHECK: }
entry:
call void @PR12470_inner(i16 signext 1)
ret void
}
Sink the collection of return instructions until after *all* simplification has been performed. This is a bit less efficient (requires another ilist walk of the basic blocks) but shouldn't matter in practice. More importantly, it's just too much work to keep track of all the various ways the return instructions can be mutated while simplifying them. This fixes yet another crasher, reported by Daniel Dunbar. llvm-svn: 154179
2012-04-06 19:21:31 +02:00
define void @crasher_inner() nounwind uwtable {
entry:
br i1 false, label %for.end28, label %for.body6
for.body6:
br i1 undef, label %for.body6, label %for.cond12.for.inc26_crit_edge
for.cond12.for.inc26_crit_edge:
br label %for.body6.1
for.end28:
ret void
for.body6.1:
br i1 undef, label %for.body6.1, label %for.cond12.for.inc26_crit_edge.1
for.cond12.for.inc26_crit_edge.1:
br label %for.body6.2
for.body6.2:
br i1 undef, label %for.body6.2, label %for.cond12.for.inc26_crit_edge.2
for.cond12.for.inc26_crit_edge.2:
br label %for.end28
}
define void @crasher_outer() {
; CHECK: @crasher_outer
; CHECK-NOT: call
; CHECK: ret void
; CHECK-NOT: ret
; CHECK: }
entry:
tail call void @crasher_inner()
ret void
}
Reference in New Issue Copy Permalink