[PATCH] D106099: [DependenceAnalysis] Guard analysis using getPointerBase()
Artem Radzikhovskyy via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Jul 16 07:08:41 PDT 2021
artemrad added inline comments.
================
Comment at: llvm/lib/Analysis/DependenceAnalysis.cpp:3556
LLVM_DEBUG(dbgs() << " DstSCEV = " << *DstSCEV << "\n");
+ if (SE->getPointerBase(SrcSCEV) != SE->getPointerBase(DstSCEV)) {
+ // If two pointers have different bases, trying to analyze indexes won't
----------------
This seems like a subset of cases we should be filtering out. Please also add checks for the access width being unaligned with the store/load size. In this case the base pointers are different but the accesses can still overlap. This case will not be caught by DependenceAnalysis.
```
define void @z0(i32* %A, i64 %n) nounwind uwtable ssp {
entry:
%arrayidx = getelementptr inbounds i32, i32* %A, i64 %n
%arrayidx_cast = bitcast i32* %arrayidx to i64*
store i64 0, i64* %arrayidx_cast, align 4
; CHECK: da analyze - confused!
; CHECK: da analyze - confused!
; CHECK: da analyze - confused!
; CHECK: da analyze - none
; CHECK: da analyze - confused!
; CHECK: da analyze - confused!
%add1 = add i64 %n, 1
%arrayidx2 = getelementptr inbounds i32, i32* %A, i64 %add1
%0 = load i32, i32* %arrayidx2, align 4
; Even if the load and store types are the same, if their
; alignments are smaller than the store size and they are
; accesses through something other than a straightforward
; gep, they can still overlap, as this access shows
%arrayidx2_cast = bitcast i32* %arrayidx2 to i64*
%1 = load i64, i64* %arrayidx2_cast, align 4
ret void
}
```
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D106099/new/
https://reviews.llvm.org/D106099
More information about the llvm-commits
mailing list