[LoopUnrollAnalyzer] Don't treat gep-instructions with simplified offset as simplified.

Summary:
Currently we consider such instructions as simplified, which is incorrect,
because if their user isn't simplified, we can't actually simplify them too.
This biases our estimates of profitability: for instance the analyzer expects
much more gains from unrolling memcpy loops than there actually are.

Reviewers: hfinkel, chandlerc

Subscribers: mzolotukhin, llvm-commits

Differential Revision: http://reviews.llvm.org/D17365

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269387 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Michael Zolotukhin 2016-05-13 01:42:34 +00:00
parent 49414096bd
commit cbd66afc98
3 changed files with 30 additions and 2 deletions

View File

@ -59,7 +59,7 @@ bool UnrolledInstAnalyzer::simplifyInstWithSCEV(Instruction *I) {
Address.Base = Base->getValue();
Address.Offset = Offset->getValue();
SimplifiedAddresses[I] = Address;
return true;
return false;
}
/// Try to simplify binary operator I.

View File

@ -1,4 +1,4 @@
; RUN: opt < %s -S -loop-unroll -unroll-max-iteration-count-to-analyze=100 -unroll-dynamic-cost-savings-discount=1000 -unroll-threshold=10 -unroll-percent-dynamic-cost-saved-threshold=50 | FileCheck %s
; RUN: opt < %s -S -loop-unroll -unroll-max-iteration-count-to-analyze=100 -unroll-dynamic-cost-savings-discount=1000 -unroll-threshold=10 -unroll-percent-dynamic-cost-saved-threshold=40 | FileCheck %s
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
@known_constant = internal unnamed_addr constant [10 x i32] [i32 1, i32 1, i32 1, i32 1, i32 1, i32 1, i32 1, i32 1, i32 1, i32 1], align 16

View File

@ -0,0 +1,28 @@
; RUN: opt < %s -S -loop-unroll -unroll-max-iteration-count-to-analyze=100 -unroll-dynamic-cost-savings-discount=1000 -unroll-threshold=10 -unroll-percent-dynamic-cost-saved-threshold=40 | FileCheck %s
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
; When examining gep-instructions we shouldn't consider them simplified if the
; corresponding memory access isn't simplified. Doing the opposite might bias
; our estimate, so that we might decide to unroll even a simple memcpy loop.
;
; Thus, the following loop shouldn't be unrolled:
; CHECK-LABEL: @not_simplified_geps
; CHECK: br i1 %
; CHECK: ret void
define void @not_simplified_geps(i32* noalias %b, i32* noalias %c) {
entry:
br label %for.body
for.body:
%iv.0 = phi i64 [ 0, %entry ], [ %iv.1, %for.body ]
%arrayidx1 = getelementptr inbounds i32, i32* %b, i64 %iv.0
%x1 = load i32, i32* %arrayidx1, align 4
%arrayidx2 = getelementptr inbounds i32, i32* %c, i64 %iv.0
store i32 %x1, i32* %arrayidx2, align 4
%iv.1 = add nuw nsw i64 %iv.0, 1
%exitcond = icmp eq i64 %iv.1, 10
br i1 %exitcond, label %for.end, label %for.body
for.end:
ret void
}