<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:jeremy.morse.llvm@gmail.com" title="Jeremy Morse <jeremy.morse.llvm@gmail.com>"> <span class="fn">Jeremy Morse</span></a>
</span> changed
<a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - [DebugInfo@O2] Salvaged memory loads can observe subsequent memory writes"
href="https://bugs.llvm.org/show_bug.cgi?id=40628">bug 40628</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Resolution</td>
<td>---
</td>
<td>FIXED
</td>
</tr>
<tr>
<td style="text-align:right;">Status</td>
<td>CONFIRMED
</td>
<td>RESOLVED
</td>
</tr>
<tr>
<td style="text-align:right;">Fixed By Commit(s)</td>
<td>
</td>
<td>353824
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - [DebugInfo@O2] Salvaged memory loads can observe subsequent memory writes"
href="https://bugs.llvm.org/show_bug.cgi?id=40628#c1">Comment # 1</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - [DebugInfo@O2] Salvaged memory loads can observe subsequent memory writes"
href="https://bugs.llvm.org/show_bug.cgi?id=40628">bug 40628</a>
from <span class="vcard"><a class="email" href="mailto:jeremy.morse.llvm@gmail.com" title="Jeremy Morse <jeremy.morse.llvm@gmail.com>"> <span class="fn">Jeremy Morse</span></a>
</span></b>
<pre>Fix review is in <a href="https://reviews.llvm.org/D57962">https://reviews.llvm.org/D57962</a>, committed in r353824, I'm
copy&pasting an example from the review here so that future archaeologists have
examples all in one place:
[...] I think the greater issue is that with DW_OP_derefs present it's
difficult to determine when code movement in optimisation passes affects
dbg.values. Consider this example, compiling "-O2 -g -fno-inline
-fno-unroll-loops" with clang@r353515:
static int qux[] = { 1, 2, 3, 4 };
int
foo(int baz, int *out)
{
int sum = 0;
for (int i = 0; i < 4; i++) {
int extra = *out;
sum += qux[i] * baz;
sum %= 4;
*out = sum;
}
return sum;
}
int
main(int argc, char **argv)
{
int out = 12;
return foo(argc, &out);
}
(The assign to 'extra' is contrived but eliminating loads is something LLVM
does all the time I believe). In this code, LICM promotes '*out' to an SSA
register for the body of the loop. However, before LICM the dbg.value for
'extra' has its load operand folded into a DW_OP_deref, and points at the
variable in 'main'. Stepping through this program in gdb, 'extra' always reads
as '12', rather than any of the values computed in the loop. Invalidating the
dbg.value at the next memory store wouldn't help, as the location specified by
the dbg.value never holds the value we're interested in.
My main point here is that not only would LICM need to be taught that moving
the store to '*out' could invalidate some dbg.values, determining which
dbg.values are affected would involve digging into DIExpressions looking for
dereferences, potentially through GEPs that were folded in too, possibly even
requiring alias analysis on any dbg.value with a deref. Which (as far as I'm
aware) is a reasonably large amount of code complexity and computation.
DeadStoreElimination would need to behave similarly (a dbg.value might try to
point at the memory of a store that's later eliminated).</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>