[llvm] r252149 - Fix LoopAccessAnalysis when potentially nullptr check are involved

Mehdi Amini via llvm-commits llvm-commits at lists.llvm.org
Wed Nov 4 21:49:44 PST 2015


Author: mehdi_amini
Date: Wed Nov  4 23:49:43 2015
New Revision: 252149

URL: http://llvm.org/viewvc/llvm-project?rev=252149&view=rev
Log:
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 <mehdi.amini at apple.com>

Added:
    llvm/trunk/test/Analysis/LoopAccessAnalysis/nullptr.ll
Modified:
    llvm/trunk/lib/Analysis/LoopAccessAnalysis.cpp

Modified: llvm/trunk/lib/Analysis/LoopAccessAnalysis.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Analysis/LoopAccessAnalysis.cpp?rev=252149&r1=252148&r2=252149&view=diff
==============================================================================
--- llvm/trunk/lib/Analysis/LoopAccessAnalysis.cpp (original)
+++ llvm/trunk/lib/Analysis/LoopAccessAnalysis.cpp Wed Nov  4 23:49:43 2015
@@ -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())

Added: llvm/trunk/test/Analysis/LoopAccessAnalysis/nullptr.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Analysis/LoopAccessAnalysis/nullptr.ll?rev=252149&view=auto
==============================================================================
--- llvm/trunk/test/Analysis/LoopAccessAnalysis/nullptr.ll (added)
+++ llvm/trunk/test/Analysis/LoopAccessAnalysis/nullptr.ll Wed Nov  4 23:49:43 2015
@@ -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
+}




More information about the llvm-commits mailing list