RPCS3/llvm
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm.git synced 2025-01-22 10:16:43 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Fix LoopAccessAnalysis when potentially nullptr check are involved

Browse Source 
Summary:
GetUnderlyingObjects() can return "null" among its list of objects,
we don't want to deduce that two pointers can point to the same
memory in this case, so filter it out.

Reviewers: anemet

Subscribers: dexonsmith, llvm-commits

From: Mehdi Amini <mehdi.amini@apple.com>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@252149 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Mehdi Amini 2015-11-05 05:49:43 +00:00
parent f8bc54d013
commit fe0b6a7f50
2 changed files with 44 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
lib/Analysis/LoopAccessAnalysis.cpp
View File

@ -268,7 +268,7 @@ void RuntimePointerChecking::groupChecks(
// ShouldRetryWithRuntimeCheck is set, and therefore UseDependencies
// is also false. In this case we will use the fallback path and create
// separate checking groups for all pointers.
// If we don't have the dependency partitions, construct a new
// checking pointer group for each pointer. This is also required
// for correctness, because in this case we can have checking between
@ -743,6 +743,11 @@ void AccessAnalysis::processMemAccesses() {
GetUnderlyingObjects(Ptr, TempObjects, DL, LI);
DEBUG(dbgs() << "Underlying objects for pointer " << *Ptr << "\n");
for (Value *UnderlyingObj : TempObjects) {
// nullptr never alias, don't join sets for pointer that have "null"
// in their UnderlyingObjects list.
if (isa<ConstantPointerNull>(UnderlyingObj))
continue;
UnderlyingObjToAccessMap::iterator Prev =
ObjToLastAccess.find(UnderlyingObj);
if (Prev != ObjToLastAccess.end())

38
test/Analysis/LoopAccessAnalysis/nullptr.ll Normal file
View File

@ -0,0 +1,38 @@
; RUN: opt -loop-accesses -analyze %s | FileCheck %s
; Test that the loop accesses are proven safe in this case.
; The analyzer uses to be confused by the "diamond" because GetUnderlyingObjects
; is saying that the two pointers can both points to null. The loop analyzer
; needs to ignore null in the results returned by GetUnderlyingObjects.
; CHECK: Memory dependences are safe with run-time checks
; ModuleID = 'bugpoint-reduced-simplified.bc'
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.11.0"
; Function Attrs: ssp uwtable
define void @foo(i1 %cond, i32* %ptr1, i32* %ptr2) {
br i1 %cond, label %.preheader, label %diamond
diamond: ; preds = %.noexc.i.i
br label %.preheader
.preheader: ; preds = %diamond, %0
%ptr1_or_null = phi i32* [ null, %0 ], [ %ptr1, %diamond ]
%ptr2_or_null = phi i32* [ null, %0 ], [ %ptr2, %diamond ]
br label %.lr.ph
.lr.ph: ; preds = %.lr.ph, %.preheader
%indvars.iv = phi i64 [ %indvars.iv.next, %.lr.ph ], [ 10, %.preheader ]
%indvars.iv.next = add nsw i64 %indvars.iv, -1
%tmp4 = getelementptr inbounds i32, i32* %ptr2_or_null, i64 %indvars.iv.next
%tmp5 = load i32, i32* %tmp4, align 4
%tmp6 = getelementptr inbounds i32, i32* %ptr1_or_null, i64 %indvars.iv.next
store i32 undef, i32* %tmp6, align 4
br i1 false, label %.lr.ph, label %.end
.end:
ret void
}