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