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/GVN/pre-single-pred.ll

46 lines
1.7 KiB
LLVM
Raw Normal View History

LoadPRE was not properly checking that the load it was PRE'ing post-dominated the block it was being hoisted to. Splitting critical edges at the merge point only addressed part of the issue; it is also possible for non-post-domination to occur when the path from the load to the merge has branches in it. Unfortunately, full anticipation analysis is time-consuming, so for now approximate it. This is strictly more conservative than real anticipation, so we will miss some cases that real PRE would allow, but we also no longer insert loads into paths where they didn't exist before. :-) This is a very slight net positive on SPEC for me (0.5% on average). Most of the benchmarks are largely unaffected, but when it pays off it pays off decently: 181.mcf improves by 4.5% on my machine. llvm-svn: 114785
2010-09-25 13:26:18 +08:00
; RUN: opt < %s -gvn -enable-load-pre -S | FileCheck %s
; This testcase assumed we'll PRE the load into %for.cond, but we don't actually
; verify that doing so is safe. If there didn't _happen_ to be a load in
; %for.end, we would actually be lengthening the execution on some paths, and
; we were never actually checking that case. Now we actually do perform some
; conservative checking to make sure we don't make paths longer, but we don't
; currently get this case, which we got lucky on previously.
;
; Now that that faulty assumption is corrected, test that we DON'T incorrectly
; hoist the load. Doing the right thing for the wrong reasons is still a bug.
Be more aggressive in doing LoadPRE by tracing backwards when a block only has a single predecessor. Patch by Jakub Staszak. llvm-svn: 72661
2009-05-31 17:03:40 +08:00
This fixes a bug introduced in 72661, which can move loads back past a check that the load address is valid, see new testcase. The test that went in with 72661 has exactly this case, except that the conditional it's moving past is checking something else; I've settled for changing that test to reference a global, not a pointer. It may be possible to scan all the tests you pass and make sure none of them are checking any component of the address, but it's not trivial and I'm not trying to do that here. llvm-svn: 73632
2009-06-18 04:48:23 +08:00
@p = external global i32
define i32 @f(i32 %n) nounwind {
Be more aggressive in doing LoadPRE by tracing backwards when a block only has a single predecessor. Patch by Jakub Staszak. llvm-svn: 72661
2009-05-31 17:03:40 +08:00
entry:
br label %for.cond
for.cond: ; preds = %for.inc, %entry
%i.0 = phi i32 [ 0, %entry ], [ %indvar.next, %for.inc ] ; <i32> [#uses=2]
%cmp = icmp slt i32 %i.0, %n ; <i1> [#uses=1]
br i1 %cmp, label %for.body, label %for.cond.for.end_crit_edge
for.cond.for.end_crit_edge: ; preds = %for.cond
br label %for.end
LoadPRE was not properly checking that the load it was PRE'ing post-dominated the block it was being hoisted to. Splitting critical edges at the merge point only addressed part of the issue; it is also possible for non-post-domination to occur when the path from the load to the merge has branches in it. Unfortunately, full anticipation analysis is time-consuming, so for now approximate it. This is strictly more conservative than real anticipation, so we will miss some cases that real PRE would allow, but we also no longer insert loads into paths where they didn't exist before. :-) This is a very slight net positive on SPEC for me (0.5% on average). Most of the benchmarks are largely unaffected, but when it pays off it pays off decently: 181.mcf improves by 4.5% on my machine. llvm-svn: 114785
2010-09-25 13:26:18 +08:00
; CHECK: for.body:
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 llvm-svn: 230794
2015-02-28 05:17:42 +08:00
; CHECK-NEXT: %tmp3 = load i32, i32* @p
Be more aggressive in doing LoadPRE by tracing backwards when a block only has a single predecessor. Patch by Jakub Staszak. llvm-svn: 72661
2009-05-31 17:03:40 +08:00
for.body: ; preds = %for.cond
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 llvm-svn: 230794
2015-02-28 05:17:42 +08:00
%tmp3 = load i32, i32* @p ; <i32> [#uses=1]
Be more aggressive in doing LoadPRE by tracing backwards when a block only has a single predecessor. Patch by Jakub Staszak. llvm-svn: 72661
2009-05-31 17:03:40 +08:00
%dec = add i32 %tmp3, -1 ; <i32> [#uses=2]
This fixes a bug introduced in 72661, which can move loads back past a check that the load address is valid, see new testcase. The test that went in with 72661 has exactly this case, except that the conditional it's moving past is checking something else; I've settled for changing that test to reference a global, not a pointer. It may be possible to scan all the tests you pass and make sure none of them are checking any component of the address, but it's not trivial and I'm not trying to do that here. llvm-svn: 73632
2009-06-18 04:48:23 +08:00
store i32 %dec, i32* @p
Be more aggressive in doing LoadPRE by tracing backwards when a block only has a single predecessor. Patch by Jakub Staszak. llvm-svn: 72661
2009-05-31 17:03:40 +08:00
%cmp6 = icmp slt i32 %dec, 0 ; <i1> [#uses=1]
br i1 %cmp6, label %for.body.for.end_crit_edge, label %for.inc
LoadPRE was not properly checking that the load it was PRE'ing post-dominated the block it was being hoisted to. Splitting critical edges at the merge point only addressed part of the issue; it is also possible for non-post-domination to occur when the path from the load to the merge has branches in it. Unfortunately, full anticipation analysis is time-consuming, so for now approximate it. This is strictly more conservative than real anticipation, so we will miss some cases that real PRE would allow, but we also no longer insert loads into paths where they didn't exist before. :-) This is a very slight net positive on SPEC for me (0.5% on average). Most of the benchmarks are largely unaffected, but when it pays off it pays off decently: 181.mcf improves by 4.5% on my machine. llvm-svn: 114785
2010-09-25 13:26:18 +08:00
; CHECK: for.body.for.end_crit_edge:
Be more aggressive in doing LoadPRE by tracing backwards when a block only has a single predecessor. Patch by Jakub Staszak. llvm-svn: 72661
2009-05-31 17:03:40 +08:00
for.body.for.end_crit_edge: ; preds = %for.body
br label %for.end
for.inc: ; preds = %for.body
%indvar.next = add i32 %i.0, 1 ; <i32> [#uses=1]
br label %for.cond
for.end: ; preds = %for.body.for.end_crit_edge, %for.cond.for.end_crit_edge
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 llvm-svn: 230794
2015-02-28 05:17:42 +08:00
%tmp9 = load i32, i32* @p ; <i32> [#uses=1]
Be more aggressive in doing LoadPRE by tracing backwards when a block only has a single predecessor. Patch by Jakub Staszak. llvm-svn: 72661
2009-05-31 17:03:40 +08:00
ret i32 %tmp9
}