From: Mehdi Amini Date: Thu, 5 Nov 2015 05:49:43 +0000 (+0000) Subject: Fix LoopAccessAnalysis when potentially nullptr check are involved X-Git-Url: http://plrg.eecs.uci.edu/git/?p=oota-llvm.git;a=commitdiff_plain;h=fe0b6a7f50fe8ad11d595d90eedfeb6484dc841f;hp=f8bc54d01330992ca8bc7c175a63824a77b07db6 Fix LoopAccessAnalysis when potentially nullptr check are involved 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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@252149 91177308-0d34-0410-b5e6-96231b3b80d8 --- diff --git a/lib/Analysis/LoopAccessAnalysis.cpp b/lib/Analysis/LoopAccessAnalysis.cpp index 58a7d08860b..49b28078c97 100644 --- a/lib/Analysis/LoopAccessAnalysis.cpp +++ b/lib/Analysis/LoopAccessAnalysis.cpp @@ -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(UnderlyingObj)) + continue; + UnderlyingObjToAccessMap::iterator Prev = ObjToLastAccess.find(UnderlyingObj); if (Prev != ObjToLastAccess.end()) diff --git a/test/Analysis/LoopAccessAnalysis/nullptr.ll b/test/Analysis/LoopAccessAnalysis/nullptr.ll new file mode 100644 index 00000000000..a72b48cc352 --- /dev/null +++ b/test/Analysis/LoopAccessAnalysis/nullptr.ll @@ -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 +}