[PATCH] Disable branch folding with MemorySanitizer

Robinson, Paul Paul_Robinson at playstation.sony.com
Mon Nov 18 14:49:10 PST 2013


Sanitizers introduce instrumentation (IIRC) so things are not quite as pristine as the debug-info mandate to have no effect on code generation.  But this is the kind of thing I did years ago on a different compiler, to improve debug-info quality at -O1.

That is:  I think this kind of optimization de-tuning is more broadly useful than just for the sanitizers and it's worth having a discussion around it.
--paulr

From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of David Blaikie
Sent: Monday, November 18, 2013 1:27 PM
To: reviews+D2214+public+18620cda62016bc9 at llvm-reviews.chandlerc.com
Cc: llvm-commits at cs.uiuc.edu; eugenis at google.com
Subject: Re: [PATCH] Disable branch folding with MemorySanitizer

Do we have precedence for this kind of change (where sanitizers affect optimizations in arbitrary internal ways - not simply by enabling/disabling certain passes)? If not, does this need some deeper discussion about alternatives (is it important that we be able to produce equivalent code without the sanitizers enabled?)?

On Mon, Nov 18, 2013 at 7:02 AM, Evgeniy Stepanov <eugenis at google.com<mailto:eugenis at google.com>> wrote:
Branch folding optimization often leads to confusing MSan reports due to lost debug info.
For example,
1: if (x < 0)
2:   if (y < 0)
3:    do_something();
is transformed into something like
  %0 = and i32 %y, %x
  %1 = icmp slt i32 %0, 0
  br i1 %1, label %if.then2, label %if.end3
where all 3 instructions are associated with line 1.

This patch disables folding of conditional branches in functions with sanitize_memory attribute.

http://llvm-reviews.chandlerc.com/D2214

Files:
  lib/Transforms/Utils/SimplifyCFG.cpp
  test/Transforms/SimplifyCFG/branch-fold-msan.ll

Index: lib/Transforms/Utils/SimplifyCFG.cpp
===================================================================
--- lib/Transforms/Utils/SimplifyCFG.cpp
+++ lib/Transforms/Utils/SimplifyCFG.cpp
@@ -1967,6 +1967,13 @@
 bool llvm::FoldBranchToCommonDest(BranchInst *BI) {
   BasicBlock *BB = BI->getParent();

+  // This optimization results in confusing MemorySanitizer reports. Use of
+  // uninitialized value in this branch instruction is reported with the
+  // predecessor's debug location.
+  if (BB->getParent()->hasFnAttribute(Attribute::SanitizeMemory) &&
+      BI->isConditional())
+    return false;
+
   Instruction *Cond = 0;
   if (BI->isConditional())
     Cond = dyn_cast<Instruction>(BI->getCondition());
Index: test/Transforms/SimplifyCFG/branch-fold-msan.ll
===================================================================
--- test/Transforms/SimplifyCFG/branch-fold-msan.ll
+++ test/Transforms/SimplifyCFG/branch-fold-msan.ll
@@ -0,0 +1,29 @@
+; RUN: opt < %s -simplifycfg -S | FileCheck %s
+
+declare void @callee()
+
+; Test that conditional branches are not folded with sanitize_memory.
+define void @caller(i32 %x, i32 %y) sanitize_memory {
+; CHECK: define void @caller(i32 [[X:%.*]], i32 [[Y:%.*]])
+; CHECK: icmp slt i32 {{.*}}[[X]]
+; CHECK: icmp slt i32 {{.*}}[[Y]]
+; CHECK: ret void
+
+entry:
+  %cmp = icmp slt i32 %x, 0
+  br i1 %cmp, label %if.then, label %if.end3
+
+if.then:                                          ; preds = %entry
+  %cmp1 = icmp slt i32 %y, 0
+  br i1 %cmp1, label %if.then2, label %if.end
+
+if.then2:                                         ; preds = %if.then
+  call void @callee()
+  br label %if.end
+
+if.end:                                           ; preds = %if.then2, %if.then
+  br label %if.end3
+
+if.end3:                                          ; preds = %if.end, %entry
+  ret void
+}

_______________________________________________
llvm-commits mailing list
llvm-commits at cs.uiuc.edu<mailto:llvm-commits at cs.uiuc.edu>
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131118/a001169c/attachment.html>


More information about the llvm-commits mailing list