Fix LSR's IV sorting function to explicitly sort by bitwidth

after sorting by stride value. This prevents it from missing
IV reuse opportunities in a host-sensitive manner.

llvm-svn: 64415
This commit is contained in:
Dan Gohman 2009-02-13 00:26:43 +00:00
parent 633b73783f
commit ba83228cdb
2 changed files with 33 additions and 4 deletions

View File

@ -1772,12 +1772,19 @@ namespace {
int64_t RV = RHSC->getValue()->getSExtValue();
uint64_t ALV = (LV < 0) ? -LV : LV;
uint64_t ARV = (RV < 0) ? -RV : RV;
if (ALV == ARV)
return LV > RV;
else
if (ALV == ARV) {
if (LV != RV)
return LV > RV;
} else {
return ALV < ARV;
}
// If it's the same value but different type, sort by bit width so
// that we emit larger induction variables before smaller
// ones, letting the smaller be re-written in terms of larger ones.
return RHS->getBitWidth() < LHS->getBitWidth();
}
return (LHSC && !RHSC);
return LHSC && !RHSC;
}
};
}

View File

@ -0,0 +1,22 @@
; RUN: llvm-as < %s | llc -march=x86-64 > %t
; RUN: grep inc %t | count 1
; RUN: not grep incw %t
@X = common global i16 0 ; <i16*> [#uses=1]
define void @foo(i32 %N) nounwind {
entry:
%0 = icmp sgt i32 %N, 0 ; <i1> [#uses=1]
br i1 %0, label %bb, label %return
bb: ; preds = %bb, %entry
%i.03 = phi i32 [ 0, %entry ], [ %indvar.next, %bb ] ; <i32> [#uses=2]
%1 = trunc i32 %i.03 to i16 ; <i16> [#uses=1]
volatile store i16 %1, i16* @X, align 2
%indvar.next = add i32 %i.03, 1 ; <i32> [#uses=2]
%exitcond = icmp eq i32 %indvar.next, %N ; <i1> [#uses=1]
br i1 %exitcond, label %return, label %bb
return: ; preds = %bb, %entry
ret void
}