[llvm-bugs] [Bug 46975] New: Long Debug Location during SimplifyCFG

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=46975

            Bug ID: 46975
           Summary: Long Debug Location during SimplifyCFG
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Transformation Utilities
          Assignee: unassignedbugs at nondot.org
          Reporter: dorit.nuzman at intel.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 23811
  --> https://bugs.llvm.org/attachment.cgi?id=23811&action=edit
Input .ll, before simplifyCFG

I think this commit (https://reviews.llvm.org/D82062) caused a debug-location
regression:

8cdd2a158c9c (Davide Italiano         2020-06-18 12:33:02 -0700 2817) 
8cdd2a158c9c (Davide Italiano         2020-06-18 12:33:02 -0700 2818)     //
Reset the condition debug location to avoid jumping on dead code
8cdd2a158c9c (Davide Italiano         2020-06-18 12:33:02 -0700 2819)     // as
the result of folding dead branches.
8cdd2a158c9c (Davide Italiano         2020-06-18 12:33:02 -0700 2821)    
CondInPred->setDebugLoc(DebugLoc());

AFAIU, during SimplifyCFG, we deliberately unset debug-location, in case the
location becomes dead-code, but in the attached scenario it doesn’t... The
result is quite painful: when looking at the compare that lost its
debug-location, before the patch we knew we're looking at this line:
"
lostLocationInfo.cl:7:22: 
if (i > 1 && i < M)
             ^
"

With this patch we know nothing:
"
lostLocationInfo.cl:1:6:
void test(__local const char * restrict A, __local char * restrict B, int N,
int M, int jCount, int jStride, __local char * restrict C) {
"


Maybe it makes more sense to remove dead-locations once they really become
dead, instead of speculatively? 


The issue can be reproduced like so:
opt < lostMetaData.before.ll -simplifycfg -S -o xx.ll

before:
land.lhs.true:                                    ; preds = %for.body6          
  %cmp10 = icmp slt i32 %i.0, %M, !dbg !32   ;<<< location info intact          
  br i1 %cmp10, label %if.then, label %if.else, !dbg !33                        


After:
for.body6:                                        ; preds = %for.cond2
  %mul = mul nsw i32 %j.0, %jStride, !dbg !28
  %add7 = add nsw i32 %i.0, %mul, !dbg !29
  %cmp8 = icmp ugt i32 %i.0, 1, !dbg !30
  %cmp10 = icmp slt i32 %i.0, %M              ;<<< location info lost
  %or.cond = and i1 %cmp8, %cmp10, !dbg !31
  br i1 %or.cond, label %if.then, label %if.else, !dbg !31


Just disabling D82062 fixes the problem:

diff --git a/llvm/lib/Transforms/Utils/SimplifyCFG.cpp
b/llvm/lib/Transforms/Utils/SimplifyCFG.cpp
index e6ca52acb4a..ad1bf811c32 100644
--- a/llvm/lib/Transforms/Utils/SimplifyCFG.cpp
+++ b/llvm/lib/Transforms/Utils/SimplifyCFG.cpp
@@ -2814,11 +2814,13 @@ bool llvm::FoldBranchToCommonDest(BranchInst *BI,
MemorySSAUpdater *MSSAU,
     // Clone Cond into the predecessor basic block, and or/and the
     // two conditions together.
     Instruction *CondInPred = Cond->clone();
-
-
+#if 0 // Undo https://reviews.llvm.org/D82062
     // Reset the condition debug location to avoid jumping on dead code
     // as the result of folding dead branches.
     CondInPred->setDebugLoc(DebugLoc());
+#endif
-
-
     RemapInstruction(CondInPred, VMap,
                      RF_NoModuleLevelChanges | RF_IgnoreMissingLocals);
     PredBlock->getInstList().insert(PBI->getIterator(), CondInPred);

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200804/0821c907/attachment.html>