Skip to content

Commit 56a1cbb

Browse files
authored
[LAA] Fix non-NFC parts of 1aded51 (#160701)
1aded51 ([LAA] Prepare to handle diff type sizes (NFC)) was supposed to be a non-functional patch, but introduced functional changes as known-non-negative and known-non-positive is not equivalent to !known-non-zero. Fix this.
1 parent 3bfcbfc commit 56a1cbb

File tree

2 files changed

+41
-1
lines changed

2 files changed

+41
-1
lines changed

llvm/lib/Analysis/LoopAccessAnalysis.cpp

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -2122,7 +2122,8 @@ MemoryDepChecker::getDependenceDistanceStrideAndSize(
21222122
// dependence.
21232123
TypeSize AStoreSz = DL.getTypeStoreSize(ATy);
21242124
TypeSize BStoreSz = DL.getTypeStoreSize(BTy);
2125-
if (AStoreSz != BStoreSz && !SE.isKnownNonZero(Dist)) {
2125+
if (AStoreSz != BStoreSz && SE.isKnownNonPositive(Dist) &&
2126+
SE.isKnownNonNegative(Dist)) {
21262127
LLVM_DEBUG(dbgs() << "LAA: possibly zero dependence distance with "
21272128
"different type sizes\n");
21282129
return Dependence::Unknown;

llvm/test/Analysis/LoopAccessAnalysis/depend_diff_types.ll

Lines changed: 39 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -187,6 +187,45 @@ exit:
187187
ret void
188188
}
189189

190+
; In the following test, dependence distance is possibly zero,
191+
; but this is not equivalent to the condition known-non-positive
192+
; and known-non-negative.
193+
194+
define void @possibly_zero_dist_diff_typesz(ptr %p) {
195+
; CHECK-LABEL: 'possibly_zero_dist_diff_typesz'
196+
; CHECK-NEXT: loop:
197+
; CHECK-NEXT: Memory dependences are safe
198+
; CHECK-NEXT: Dependences:
199+
; CHECK-NEXT: Forward:
200+
; CHECK-NEXT: %ld.p = load i32, ptr %gep.p.iv.i32, align 1 ->
201+
; CHECK-NEXT: store i16 %trunc, ptr %gep.p.iv.i16, align 1
202+
; CHECK-EMPTY:
203+
; CHECK-NEXT: Run-time memory checks:
204+
; CHECK-NEXT: Grouped accesses:
205+
; CHECK-EMPTY:
206+
; CHECK-NEXT: Non vectorizable stores to invariant address were not found in loop.
207+
; CHECK-NEXT: SCEV assumptions:
208+
; CHECK-EMPTY:
209+
; CHECK-NEXT: Expressions re-written:
210+
;
211+
entry:
212+
br label %loop
213+
214+
loop:
215+
%iv = phi i16 [ 0, %entry ], [ %iv.next, %loop ]
216+
%gep.p.iv.i32 = getelementptr inbounds nuw i32, ptr %p, i16 %iv
217+
%ld.p = load i32, ptr %gep.p.iv.i32, align 1
218+
%trunc = trunc i32 %ld.p to i16
219+
%gep.p.iv.i16 = getelementptr inbounds nuw i16, ptr %p, i16 %iv
220+
store i16 %trunc, ptr %gep.p.iv.i16, align 1
221+
%iv.next = add nuw nsw i16 %iv, 1
222+
%exit.cond = icmp eq i16 %iv.next, 32
223+
br i1 %exit.cond, label %exit, label %loop
224+
225+
exit:
226+
ret void
227+
}
228+
190229
; In the following test, the sink is loop-invariant.
191230

192231
define void @type_size_equivalence_sink_loopinv(ptr nocapture %vec, i64 %n) {

0 commit comments

Comments
 (0)