[llvm-commits] [llvm] r149925 - in /llvm/trunk: lib/Analysis/MemoryDependenceAnalysis.cpp test/Instrumentation/AddressSanitizer/asan-vs-gvn.ll

Kostya Serebryany kcc at google.com
Mon Feb 6 14:48:56 PST 2012


Author: kcc
Date: Mon Feb  6 16:48:56 2012
New Revision: 149925

URL: http://llvm.org/viewvc/llvm-project?rev=149925&view=rev
Log:
The patch resolves the conflict between AddressSanitizer and load widening (GVN).
The problem initially reported by Mozilla folks (http://code.google.com/p/address-sanitizer/issues/detail?id=20),
but it also prevents us from enabling LLVM bootstrap with AddressSanitizer.

Added:
    llvm/trunk/test/Instrumentation/AddressSanitizer/asan-vs-gvn.ll
Modified:
    llvm/trunk/lib/Analysis/MemoryDependenceAnalysis.cpp

Modified: llvm/trunk/lib/Analysis/MemoryDependenceAnalysis.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Analysis/MemoryDependenceAnalysis.cpp?rev=149925&r1=149924&r2=149925&view=diff
==============================================================================
--- llvm/trunk/lib/Analysis/MemoryDependenceAnalysis.cpp (original)
+++ llvm/trunk/lib/Analysis/MemoryDependenceAnalysis.cpp Mon Feb  6 16:48:56 2012
@@ -323,6 +323,14 @@
         !TD.fitsInLegalInteger(NewLoadByteSize*8))
       return 0;
 
+    if (LIOffs+NewLoadByteSize > MemLocEnd &&
+        LI->getParent()->getParent()->hasFnAttr(Attribute::AddressSafety)) {
+      // We will be reading past the location accessed by the original program.
+      // While this is safe in a regular build, Address Safety analysis tools
+      // may start reporting false warnings. So, don't do widening.
+      return 0;
+    }
+
     // If a load of this width would include all of MemLoc, then we succeed.
     if (LIOffs+NewLoadByteSize >= MemLocEnd)
       return NewLoadByteSize;

Added: llvm/trunk/test/Instrumentation/AddressSanitizer/asan-vs-gvn.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Instrumentation/AddressSanitizer/asan-vs-gvn.ll?rev=149925&view=auto
==============================================================================
--- llvm/trunk/test/Instrumentation/AddressSanitizer/asan-vs-gvn.ll (added)
+++ llvm/trunk/test/Instrumentation/AddressSanitizer/asan-vs-gvn.ll Mon Feb  6 16:48:56 2012
@@ -0,0 +1,43 @@
+; RUN: opt < %s -basicaa -gvn -asan -S | FileCheck %s
+; ASAN conflicts with load widening iff the widened load accesses data out of bounds
+; (while the original unwidened loads do not).
+; http://code.google.com/p/address-sanitizer/issues/detail?id=20#c1
+
+
+; 32-bit little endian target.
+target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:128:128-n8:16:32"
+
+%struct_of_7_bytes_4_aligned = type { i32, i8, i8, i8}
+
+ at f = global %struct_of_7_bytes_4_aligned zeroinitializer, align 4
+
+; Accessing bytes 4 and 6, not ok to widen to i32 if address_safety is set.
+
+define i32 @test_widening_bad(i8* %P) nounwind ssp noredzone address_safety {
+entry:
+  %tmp = load i8* getelementptr inbounds (%struct_of_7_bytes_4_aligned* @f, i64 0, i32 1), align 4
+  %conv = zext i8 %tmp to i32
+  %tmp1 = load i8* getelementptr inbounds (%struct_of_7_bytes_4_aligned* @f, i64 0, i32 3), align 1
+  %conv2 = zext i8 %tmp1 to i32
+  %add = add nsw i32 %conv, %conv2
+  ret i32 %add
+; CHECK: @test_widening_bad
+; CHECK: __asan_report_load1
+; CHECK: __asan_report_load1
+; CHECK-ret i32
+}
+
+;; Accessing byets 4 and 5. Ok to widen to i16.
+
+define i32 @test_widening_ok(i8* %P) nounwind ssp noredzone address_safety {
+entry:
+  %tmp = load i8* getelementptr inbounds (%struct_of_7_bytes_4_aligned* @f, i64 0, i32 1), align 4
+  %conv = zext i8 %tmp to i32
+  %tmp1 = load i8* getelementptr inbounds (%struct_of_7_bytes_4_aligned* @f, i64 0, i32 2), align 1
+  %conv2 = zext i8 %tmp1 to i32
+  %add = add nsw i32 %conv, %conv2
+  ret i32 %add
+; CHECK: @test_widening_ok
+; CHECK: __asan_report_load1
+; CHECK-ret i32
+}





More information about the llvm-commits mailing list