<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] MachineSink can unsoundly extend variable location ranges"
href="https://bugs.llvm.org/show_bug.cgi?id=44117">44117</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[DebugInfo@O2] MachineSink can unsoundly extend variable location ranges
</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>Keywords</th>
<td>wrong-debug
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</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>aprantl@apple.com, chackz0x12@gmail.com, greg.bedwell@sony.com, llvm-bugs@lists.llvm.org, orlando.hyams@sony.com, paul.robinson@am.sony.com, stephen.tozer@sony.com, vsk@apple.com
</td>
</tr>
<tr>
<th>Blocks</th>
<td>38768
</td>
</tr></table>
<p>
<div>
<pre>This is a bug report to document an edge case to do with the machine-sink pass
that I don't think can be easily solved.
Here's a highly contrived reproducer, that when compiled with trunk "-O2 -g -c
-fno-unroll-loops" will sink the computation of "a & 0xFFFF" into the final
block (where there's the assign to global). It also sinks the (salvaged)
DBG_VALUE for the first value of "badgers" too.
--------8<--------
int global, global2;
int
foo(int a, int b)
{
int floogie = a & 0xFFFF;
int badgers = floogie + 12;
if (a == 1234567) {
badgers = global2; // body uninteresting, but "badgers" reassigned
badgers ^= a;
global2 = badgers + 1;
if (b == 12)
return global;
}
global = floogie;
return global;
}
-------->8--------
Normally, in the end block, we would not be able to compute a location for
"badgers", because we don't know which side of the "a == 1234567" condition was
taken. The location would be empty / optimised out.
However, because the DBG_VALUE for "badgers" sinks into that end block, it
specifies the variable location as being "floogie+12", regardless of which side
of the condition was taken, which is not a true representation of the original
program.
This is actually really hard to solve with our current model. If there were no
further assignments to "badgers" on any path from the source to destination
block, then the DBG_VALUE sinking would be absolutely fine and desirable.
However, discovering whether this is true or not involves examining every block
that _might_ be on a path from the source to the destination position, which
AFAIUI is expensive. Machine sinking doesn't currently do this level of
analysis, so I haven't tried to fix it yet.
This technically applies to any pass that does any kind of sinking. Instcombine
will only sink where there isn't any control flow present though, so this isn't
a problem inscombine currently demonstrates, I think.
Time for Jeremy's pet peeve: in a more ideal world, one where the
machine-location and the instruction-location were separate, we could record an
assignment / location-change in the first block of the program, and the
machine-location in the last block, and leave it to a debug post-processor to
work these things out, when we actually do a full dataflow analysis.</pre>
</div>
</p>
<div id="referenced">
<hr style="border: 1px dashed #969696">
<b>Referenced Bugs:</b>
<ul>
<li>
[<a class="bz_bug_link
bz_status_NEW "
title="NEW - [meta][DebugInfo] Umbrella bug for poor debug experiences"
href="https://bugs.llvm.org/show_bug.cgi?id=38768">Bug 38768</a>] [meta][DebugInfo] Umbrella bug for poor debug experiences
</li>
</ul>
</div>
<br>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>