<div dir="ltr">Really broadly, I think Jeremy has done a lot of good work here, and if he thinks this is ready to enable for x86, we should go forward with it.<div><br></div><div>Previously, I have expressed concerns about this design direction because instructions do not necessarily remain in source order. However, I think the benefit of the increased variable availability probably outweighs the cost of variable values that don't correspond to the current source location, and we should go forward with this.</div><div><br></div><div>Thanks for working on this, Jeremy!</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 10, 2021 at 11:49 AM Jeremy Morse via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi llvm-dev@,<br>
<br>
tl;dr: Is it okay to enable value tracking (aka "instruction<br>
referencing") to preserve debug-info variable locations, by default,<br>
for x86_64?<br>
<br>
The high-level summary of instruction referencing is that, after<br>
instruction selection, instead of describing variable locations as a<br>
virtual register, we indirectly refer to the MachineInstr operand<br>
where the variables value is defined. Once compilation is done, some<br>
standard SSA analysis is used to determine the locations that values<br>
are in, and what locations contain variable values. The benefit is<br>
improved variable location coverage because we no longer have to act<br>
conservatively during register allocation. More in the original RFC<br>
[0].<br>
<br>
We've (Sony) tested this internally and it works well; Caroline kindly<br>
tested it [1] on some Google benchmarks and it seemed to work well<br>
there too. It's currently in-tree and can be enabled by passing<br>
-Xclang -fexperimental-debug-variable-locations to clang, or<br>
-experimental-debug-variable-locations in LLVM options.<br>
<br>
Probably the biggest caveat right now is that I'd like to only enable<br>
for x86_64: this isn't due to any design limitation, it's just where<br>
I've been doing all the testing, and it's largely untested on most<br>
other architectures. I've run a stage2 cross compile to aarch64 for<br>
clang as it's another popular arch, but that's all. There's a<br>
migration guide in [2] of how other architectures can benefit: I would<br>
suggest that other architectures opt into instruction referencing when<br>
they're ready.<br>
<br>
Here's a list of "remaining work" that are things I consider<br>
incomplete about the new implementation:<br>
 * A bunch of tests need to be updated to check for the correct<br>
outputs in this new mode, see D113194 [3].<br>
 * Variadic variable locations aren't implemented -- this is probably<br>
a week or two of work.<br>
 * I've got unit tests for maybe 85% of the important parts of the<br>
"new" LiveDebugValues, but there are some gaps.<br>
 * It can be non-trivial for humans to interpret variable locations<br>
[4] in MIR, some printing improvements are needed.<br>
<br>
There are some downsides that can be discussed too: most significantly<br>
that it's slower on CTMark [5]. The relevant configs there are<br>
NewPM-ReleaseLTO-g and LegacyPM-ReleaseLTO-g, which are the only<br>
configs that get optimisations and debug-info. Strictly speaking, this<br>
slowdown is unavoidable because there's more information and more<br>
accurate information being produced (one CTMark binary is almost 20%<br>
larger due to extra debug-info), but it's still unfortunate. There are<br>
some optimisations that can still be applied, and with instruction<br>
referencing we can trivially compress all sequences of debug<br>
instructions into a single instruction. Reids experiments [6] on<br>
debug-instruction contribution to compile times (applied to IR not<br>
MIR) suggest that could be a performance win. I should be able to<br>
prototype this sometime soon.<br>
<br>
Other downsides:<br>
 * Support for i686 FP registers is nonexistant; due to it being a<br>
stack, it's extra effort to track, which I haven't bothered to do yet.<br>
Normal DBG_VALUEs don't do particularly well either.<br>
 * In the original RFC I pointed out that we can define a debug<br>
use-before-def as a missing location at the point of any instruction<br>
not dominated by the def, and as a normal location at any instruction<br>
dominated by the def. Turning on instruction referencing by default<br>
means this interpretation is implicitly accepted.<br>
<br>
In my opinion it's mature enough to turn on by default (for x86_64),<br>
ideally in good time for LLVM14's branch date, and I'm confident that<br>
the remaining work can be done by the branch date. What do other<br>
people think?<br>
<br>
[0] <a href="https://lists.llvm.org/pipermail/llvm-dev/2020-February/139440.html" rel="noreferrer" target="_blank">https://lists.llvm.org/pipermail/llvm-dev/2020-February/139440.html</a><br>
[1] <a href="https://lists.llvm.org/pipermail/llvm-dev/2021-September/152457.html" rel="noreferrer" target="_blank">https://lists.llvm.org/pipermail/llvm-dev/2021-September/152457.html</a><br>
[2] <a href="https://reviews.llvm.org/D113586" rel="noreferrer" target="_blank">https://reviews.llvm.org/D113586</a><br>
[3] <a href="https://reviews.llvm.org/D113194" rel="noreferrer" target="_blank">https://reviews.llvm.org/D113194</a><br>
[4] <a href="https://reviews.llvm.org/D111317#3057563" rel="noreferrer" target="_blank">https://reviews.llvm.org/D111317#3057563</a><br>
[5] <a href="http://llvm-compile-time-tracker.com/compare.php?from=8a2f40b403745fe7ba305efa86f95f3568cbd0a6&to=7436a1baa8692b4ed5ff577c1a17ed1b1e916961&stat=instructions" rel="noreferrer" target="_blank">http://llvm-compile-time-tracker.com/compare.php?from=8a2f40b403745fe7ba305efa86f95f3568cbd0a6&to=7436a1baa8692b4ed5ff577c1a17ed1b1e916961&stat=instructions</a><br>
[6] <a href="https://lists.llvm.org/pipermail/llvm-dev/2018-October/127140.html" rel="noreferrer" target="_blank">https://lists.llvm.org/pipermail/llvm-dev/2018-October/127140.html</a><br>
<br>
--<br>
Thanks,<br>
Jeremy<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>