<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I totally agree with this. Thank you, Jeremy, for this great work!</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Djordje</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Adrian Prantl <aprantl@apple.com><br>
<b>Sent:</b> Thursday, November 11, 2021 11:41 PM<br>
<b>To:</b> Reid Kleckner <rnk@google.com><br>
<b>Cc:</b> Jeremy Morse <jeremy.morse.llvm@gmail.com>; llvm-dev <llvm-dev@lists.llvm.org>; David Blaikie <dblaikie@gmail.com>; Djordje Todorovic <Djordje.Todorovic@syrmia.com>; Cazalet-Hyams, Orlando <orlando.hyams@sony.com>; Tozer, Stephen <stephen.tozer@sony.com>;
Paul Robinson <paul.robinson@sony.com>; Caroline Tice <cmtice@google.com>; Amy Huang <akhuang@google.com><br>
<b>Subject:</b> Re: [llvm-dev] [DebugInfo][RFC] Enabling "instruction referencing" variable locations for x86_64</font>
<div> </div>
</div>
<div class="" style="word-wrap:break-word; line-break:after-white-space"><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="x_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="x_gmail_quote">
<div dir="ltr" class="x_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="x_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="">
</div>
</body>
</html>