<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">The actual DWARF emission for call site parameters is gated inside of DwarfDebug::constructCallSiteEntryDIEs by `tuneForGDB() || tuneForLLDB()`.<div class=""><br class=""></div><div class="">However, we are creating+updating CallSiteInfo (basically, in-memory only bookkeeping used by the backend to keep track of call sites) even when the debugger tuning is set to the Sony debugger. If this creates problems, feel free to file a bug and I'll address it. However, there's an upside to maintaining all this CallSiteInfo even if TAG_call_site_parameters won't be emitted. The backend asserts whenever a MachineInstr carrying CallSiteInfo is destroyed without the call information being updated. This provides useful test coverage.</div><div class=""><br class=""></div><div class="">vedant<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Feb 7, 2020, at 2:50 PM, Robinson, Paul <<a href="mailto:paul.robinson@sony.com" class="">paul.robinson@sony.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">I’ve asked someone to check with our (Sony) debugger people, likely hear back early next week. I’d say proceed with having it default on/off based on tuning as you described, and if my guys want to see it turned on, we can fix it later. I have to say, a quick skim through D73534 made me think it’s not controlled that way right now, is that still a TODO?<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Thanks for all the work to support this feature!<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">--paulr<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="border-style: none none none solid; border-left-width: 1.5pt; border-left-color: blue; padding: 0in 0in 0in 4pt;" class=""><div class=""><div style="border-style: solid none none; border-top-width: 1pt; border-top-color: rgb(225, 225, 225); padding: 3pt 0in 0in;" class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><b class="">From:</b><span class="Apple-converted-space"> </span>llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" style="color: purple; text-decoration: underline;" class="">llvm-dev-bounces@lists.llvm.org</a>><span class="Apple-converted-space"> </span><b class="">On Behalf Of<span class="Apple-converted-space"> </span></b>Vedant Kumar via llvm-dev<br class=""><b class="">Sent:</b><span class="Apple-converted-space"> </span>Friday, February 7, 2020 2:04 PM<br class=""><b class="">To:</b><span class="Apple-converted-space"> </span>David Blaikie <<a href="mailto:dblaikie@gmail.com" style="color: purple; text-decoration: underline;" class="">dblaikie@gmail.com</a>><br class=""><b class="">Cc:</b><span class="Apple-converted-space"> </span><a href="mailto:llvm-dev@lists.llvm.org" style="color: purple; text-decoration: underline;" class="">llvm-dev@lists.llvm.org</a>;<span class="Apple-converted-space"> </span><a href="mailto:nikola.prica@rt-rk.com" style="color: purple; text-decoration: underline;" class="">nikola.prica@rt-rk.com</a>;<span class="Apple-converted-space"> </span><a href="mailto:ibaev@cisco.com" style="color: purple; text-decoration: underline;" class="">ibaev@cisco.com</a>;<span class="Apple-converted-space"> </span><a href="mailto:asowda@cisco.com" style="color: purple; text-decoration: underline;" class="">asowda@cisco.com</a><br class=""><b class="">Subject:</b><span class="Apple-converted-space"> </span>Re: [llvm-dev] Enabling debug entry value production by default<o:p class=""></o:p></div></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Yep, TAG_call_site_parameter and its children shouldn't require any extra relocations. Thanks!<o:p class=""></o:p></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">vedant<o:p class=""></o:p></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><br class=""><br class=""><o:p class=""></o:p></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">On Feb 7, 2020, at 2:01 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" style="color: purple; text-decoration: underline;" class="">dblaikie@gmail.com</a>> wrote:<o:p class=""></o:p></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">For that sort of small growth, if it doesn't add more relocations (I think the call sites need them (but they're already emitted/that's not what we're discussing enabling here), but call value descriptions don't), sounds good to me :)<o:p class=""></o:p></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">On Fri, Feb 7, 2020 at 12:04 PM Vedant Kumar <<a href="mailto:vedant_kumar@apple.com" style="color: purple; text-decoration: underline;" class="">vedant_kumar@apple.com</a>> wrote:<o:p class=""></o:p></div></div><blockquote style="border-style: none none none solid; border-left-width: 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin-left: 4.8pt; margin-right: 0in;" class=""><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Hi all,<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">I think we've reached a state where we're ready to enable debug entry value production by default for the x86_64, ARM, and AArch64 targets. For context, this is a debug info feature that allows debuggers to recover the value of unmodified optimized-out parameters by 'going up' a stack frame and interpreting spilled values, constants, etc. to work out what was passed to the callee. There's a nice write-up about the impact of this feature in [3]. A big thank you to all of contributors who've helped us get here (I've tried to CC everyone, sincere apologies if I've accidentally left you out).<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">I believe Djordje and I have shown that there isn't an outsized binary size or compile time impact of enabling this feature. The aggregate size of DWARF in a stage2 x86_64 RelWithDebInfo clang build grows by under 0.2%, and we didn't find a significant compile time impact. We've shared CTMark results (both compile-time & DWARF section size numbers), as well as a size analysis of stage2 builds of {llc, clang, lldb} in [1].<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Djordje has also shared a nice location statistics comparison chart in [1], showing increased variable availability with entry values enabled.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">For my part, I instrumented lldb's DWARFExpression::Evaluate method to log instances in which a variable location is unavailable. I then used a script [4] to single-step through a stage2 RelWithDebInfo+entryvals clang binary as it was compiling sqlite3.c, printing local variables at each stop. Without entry values, lldb reported "variable not available" 883,918 times. With entry values lldb reported "variable not available" 687,899 times (a 22% drop).<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Does anyone have concerns about enabling this feature?<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">thanks,<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">vedant<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">[1] <a href="https://reviews.llvm.org/D73534" target="_blank" style="color: purple; text-decoration: underline;" class="">[DebugInfo] Enable the debug entry values feature by default</a><o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">[2] <a href="https://reviews.llvm.org/D73700" target="_blank" style="color: purple; text-decoration: underline;" class="">[CallSiteInfo] Fix the assertions regarding updating the CallSiteInfo</a>, <a href="https://reviews.llvm.org/D74122" target="_blank" style="color: purple; text-decoration: underline;" class="">[CallSiteInfo] Use the isCandidateForCallSiteEntry() when update the cs info</a><o:p class=""></o:p></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">[3]<span class="Apple-converted-space"> </span><a href="https://robert.ocallahan.org/2018/11/comparing-quality-of-debug-information.html" target="_blank" style="color: purple; text-decoration: underline;" class="">https://robert.ocallahan.org/2018/11/comparing-quality-of-debug-information.html</a><o:p class=""></o:p></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">[4] <a href="https://gist.github.com/vedantk/7602b20a9e1d44c42d32dcca36591cc0" target="_blank" style="color: purple; text-decoration: underline;" class="">https://gist.github.com/vedantk/7602b20a9e1d44c42d32dcca36591cc0</a></div></div></div></blockquote></div></div></blockquote></div></div></div></div></div></blockquote></div><br class=""></div></body></html>