[llvm-bugs] [Bug 48091] New: [DebugInfo at O2] Filtering out-of-scope variables drops many legitimate locations

[via llvm-bugs]

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

            Bug ID: 48091
           Summary: [DebugInfo at O2] Filtering out-of-scope variables drops
                    many legitimate locations
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: jeremy.morse.llvm at gmail.com
                CC: llvm-bugs at lists.llvm.org

The VarLoc based LiveDebugValues implementation has a filter in the 'join'
method, to cease propagating variable locations that have gone out of scope. I
believe the aim of this is to prevent LiveDebugValues needlessly computing the
location of every variable for every instruction, even those that are only in
scope for a few instructions.

Clearly this is effective at moderating compile times, however it also seems to
damage location coverage too. Specifically: if you have, say, an X86 CMOV64
instruction:
  CMP64rr $rbx, $rcx, implicit-def $eflags
  $rbx = CMOV64rr $rbx (tied-def 0), $rcx, 7, implicit $eflags, debug-location
!1

Then occasionally the X86 backend will implement this with control flow:
  CMP64rr $rbx, $rcx, implicit-def $eflags
  JCC_1 %bb.2, 7, debug-location !1

bb.1:
  $rbx = COPY $rcx, debug-location !1

bb.2:
   ...

Unfortunately, this effectively becomes a notch filter for variables that are
in scope for DILocation !1. Any variables that aren't in scope in bb.1 will be
dropped, and subsequently cause the same variables to be dropped from bb.2
onwards. That means any LLVM-IR select instruction can potentially lead to
neighbouring variable locations being dropped, depending on their scopes. In
terms of impact, here's llvm-locstats for a clang-3.4 build with and without
the out-of-scope filter. With filter:

 =================================================
     cov%           samples         percentage(~)
 -------------------------------------------------
   0%               765406               22%
   (0%,10%)          45179                1%
   [10%,20%)         51699                1%
   [20%,30%)         52044                1%
   [30%,40%)         46905                1%
   [40%,50%)         48292                1%
   [50%,60%)         61342                1%
   [60%,70%)         58315                1%
   [70%,80%)         69848                2%
   [80%,90%)         81937                2%
   [90%,100%)       101384                2%
   100%            2032034               59%
 =================================================
 -the number of debug variables processed: 3414385
 -PC ranges covered: 61%
 -------------------------------------------------
 -total availability: 64%
 =================================================

Without:

 =================================================
     cov%           samples         percentage(~)
 -------------------------------------------------
   0%               765357               22%
   (0%,10%)          45168                1%
   [10%,20%)         51584                1%
   [20%,30%)         51911                1%
   [30%,40%)         46569                1%
   [40%,50%)         47978                1%
   [50%,60%)         60356                1%
   [60%,70%)         53071                1%
   [70%,80%)         56018                1%
   [80%,90%)         79131                2%
   [90%,100%)       103664                3%
   100%            2059075               60%
 =================================================
 -the number of debug variables processed: 3419882
 -PC ranges covered: 61%
 -------------------------------------------------
 -total availability: 65%
 =================================================

Importantly, there are an additional ~27k variables in the 100% range bucket,
mostly moved up from the 60-99% ranges. Presumably these are long lived
variables that have their lifetimes artificially interrupted by the scope
filter. A similar amount of improvement occurs for InstrRefBasedLDV.

IMO, this is eminently solvable in InstrRefBasedLDV -- as it deals with things
in terms of transfer functions, we should be able to invent transfer functions
between isolated segments of particular scopes using dominance information.

-- 
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/20201105/38122637/attachment.html>