[llvm-bugs] [Bug 39940] New: [DebugInfo at O2] CodeGenPrepare address-mode sinking limits dbg.value validity

[via llvm-bugs]

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

            Bug ID: 39940
           Summary: [DebugInfo at O2] CodeGenPrepare address-mode sinking
                    limits dbg.value validity
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Keywords: wrong-debug
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: jeremy.morse.llvm at gmail.com
          Reporter: jeremy.morse.llvm at gmail.com
                CC: chackz0x12 at gmail.com, dblaikie at gmail.com,
                    greg.bedwell at sony.com,
                    international.phantom at gmail.com,
                    llvm-bugs at lists.llvm.org, paul.robinson at am.sony.com
            Blocks: 38754, 38768

In the code below, CodeGenPrepare duplicates the GEP calculating the %bees
pointer and sinks the copy into the "next:" block. This is fine, and is
designed to allow the address calculations to be folded into a machine
addressing mode. The dbg.value for %bees is left in a BB where there are no
other uses of %bees, and normally CodeGenPrepare's placeDbgValues would move
the dbg.value into the earlier BB to avoid limitations in SelectionDAG.

However, as explored in bug 38754, this isn't a good solution, and causes the
appearance of variables to the developer to be re-ordered in the debugger. When
placeDbgValues is turned off, the dbg.value stays in the later BB. Then in
SelectionDAG, because %bees isn't used outside of the first BB, no VReg is
allocated to it, and there's no way to turn the dbg.value into a legal
DBG_VALUE. The dbg.value is subsequently dropped.

I've been using the latest trunk (r348754) and have been running "llc
-stop-after=codegenprepare". The fix seems obvious (update debug users in
CodeGenPrepare::optimizeMemoryInst) however it's not clear whether a fix can be
tested if it depends on placeDbgValues being disabled.

-------->8--------
declare void @llvm.dbg.value(metadata, metadata, metadata)

define i32 @lala(i32 *%ptr, i1 %arg) {
  %bees = getelementptr i32, i32* %ptr, i32 4
  %loaded = load i32, i32 *%bees
  br i1 %arg, label %next, label %face

next:
  call void @llvm.dbg.value(metadata i32 *%bees, metadata !1, metadata
!DIExpression()), !dbg !6
  store i32 1, i32 *%bees
  ret i32 1

face:
  ret i32 0
}

!llvm.module.flags = !{!4}
!llvm.dbg.cu = !{!2}
!1 = !DILocalVariable(name: "bees", scope: !5, type: null)
!2 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !3, producer:
"beards", isOptimized: true, runtimeVersion: 4, emissionKind: FullDebug)
!3 = !DIFile(filename: "bees.cpp", directory: "")
!4 = !{i32 2, !"Debug Info Version", i32 3}
!5 = distinct !DISubprogram(name: "nope", scope: !2, file: !3, line: 1, unit:
!2)
!6 = !DILocation(line: 0, scope: !5)
--------8<--------


Referenced Bugs:

https://bugs.llvm.org/show_bug.cgi?id=38754
[Bug 38754] [DebugInfo at O2][Dexter] Illegal value appears in variable when
conditional blocks folded
https://bugs.llvm.org/show_bug.cgi?id=38768
[Bug 38768] [meta][DebugInfo] Umbrella bug for poor debug experiences
-- 
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/20181210/7d42a179/attachment.html>