<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - [DebugInfo@O2] Filtering out-of-scope variables drops many legitimate locations"
href="https://bugs.llvm.org/show_bug.cgi?id=48091">48091</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[DebugInfo@O2] Filtering out-of-scope variables drops many legitimate locations
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Common Code Generator Code
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>jeremy.morse.llvm@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>