<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 7, 2016 at 11:02 AM Teresa Johnson <<a href="mailto:tejohnson@google.com">tejohnson@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">+pcc to answer question about global variable list on CU<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Thanks for the comments, responses below.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Teresa<br class="gmail_msg"><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg">On Wed, Dec 7, 2016 at 10:36 AM, Duncan P. N. Exon Smith <span dir="ltr" class="gmail_msg"><<a href="mailto:dexonsmith@apple.com" class="gmail_msg" target="_blank">dexonsmith@apple.com</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-4457950798788683949gmail- gmail_msg"><br class="gmail_msg">
> On 2016-Dec-07, at 10:14, Teresa Johnson <<a href="mailto:tejohnson@google.com" class="gmail_msg" target="_blank">tejohnson@google.com</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> A couple weeks ago I sat down with David Blaikie to figure out what we could trim when importing debug metadata during function importing. I have a prototype that reduces the resulting .o sizes significantly with ThinLTO -g. However, I ran into some issues when cleaning up part of this in preparation for a patch. Since Mehdi indicated that he and Adrian were going to be looking at this as well shortly, I wanted to send out a summary of what David Blaikie and I discussed, what I have right now, and the issues I am hitting along with possible solutions.<br class="gmail_msg">
><br class="gmail_msg">
> There was a related older patch where I did some of the same things (D16440: [ThinLTO] Link in only necessary DICompileUnit operands), but that was made obsolete by a number of changes, such as the reversal of GlobalVariable/DIGlobalVariable edges, and a number of debug metadata changes done by Duncan (and Adrian I think?). So I started from scratch this time.<br class="gmail_msg">
><br class="gmail_msg">
> Here's what I came up with after discussing what to import with David. Specifically, how to handle fields when importing a DICompileUnit:<br class="gmail_msg">
<br class="gmail_msg">
</span>Do you have a profile of which (if any) of these is causing the debug info bloat?<br class="gmail_msg">
<br class="gmail_msg">
I worry/suspect that much of the bloat could be in the DILocation chains (line-table), which are generally non-mergeable.<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Here is a breakdown of the debug section sizes aggregated across all .o files for a build of Chromium with -g2. These are both with ThinLTO, but the first column is with all function importing disabled:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><font face="monospace, monospace" class="gmail_msg"> <span class="m_-4457950798788683949gmail-Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span>No importing<span class="m_-4457950798788683949gmail-Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span>Normal importing (aka "Head" in the below graph)</font></div><div class="gmail_msg"><font face="monospace, monospace" class="gmail_msg">.debug_abbrev<span class="m_-4457950798788683949gmail-Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span>32013702<span class="m_-4457950798788683949gmail-Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span>60570915</font></div><div class="gmail_msg"><font face="monospace, monospace" class="gmail_msg">.debug_info<span class="m_-4457950798788683949gmail-Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span>1714741154<span class="m_-4457950798788683949gmail-Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span><a href="tel:(872)%20460-3593" value="+18724603593" class="gmail_msg" target="_blank">8724603593</a></font></div><div class="gmail_msg"><font face="monospace, monospace" class="gmail_msg">.debug_line<span class="m_-4457950798788683949gmail-Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span>108033535<span class="m_-4457950798788683949gmail-Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span>440090737</font></div><div class="gmail_msg"><font face="monospace, monospace" class="gmail_msg">.debug_loc<span class="m_-4457950798788683949gmail-Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span>178426363<span class="m_-4457950798788683949gmail-Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span>264907421</font></div><div class="gmail_msg"><font face="monospace, monospace" class="gmail_msg">.debug_macinfo<span class="m_-4457950798788683949gmail-Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span>17820 <span class="m_-4457950798788683949gmail-Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span>17820</font></div><div class="gmail_msg"><font face="monospace, monospace" class="gmail_msg">.debug_pubnames<span class="m_-4457950798788683949gmail-Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span>251081673<span class="m_-4457950798788683949gmail-Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span>661630495</font></div><div class="gmail_msg"><font face="monospace, monospace" class="gmail_msg">.debug_pubtypes<span class="m_-4457950798788683949gmail-Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span>284086653<span class="m_-4457950798788683949gmail-Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span>1867377375</font></div><div class="gmail_msg"><font face="monospace, monospace" class="gmail_msg">.debug_ranges<span class="m_-4457950798788683949gmail-Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span>65470016<span class="m_-4457950798788683949gmail-Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span>106560864</font></div><div class="gmail_msg"><font face="monospace, monospace" class="gmail_msg">.debug_str<span class="m_-4457950798788683949gmail-Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span><a href="tel:(330)%20412-2338" value="+13304122338" class="gmail_msg" target="_blank">3304122338</a><span class="m_-4457950798788683949gmail-Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span><a href="tel:(901)%20308-4756" value="+19013084756" class="gmail_msg" target="_blank">19013084756</a></font></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><img src="cid:ii_iwfakx380_158daa15558a5da9" alt="image.png" class="" style="max-width: 100%;"><br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I'm not sure if this answers your question above about DILocation chains though - would that be directly translated into .debug_loc size?</div></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="m_-4457950798788683949gmail- gmail_msg"><br class="gmail_msg">
> a) List of enum types<br class="gmail_msg">
> - Not needed in the importing module: change to nullptr<br class="gmail_msg">
<br class="gmail_msg">
</span>Seems reasonable for -flto=thin (incorrect for -flto=full, though).<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Right, all this is for ThinLTO - I haven't thought about Full LTO as I am concerned about ThinLTO importing-specific bloat.</div></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="m_-4457950798788683949gmail- gmail_msg"><br class="gmail_msg">
> b) List of macros<br class="gmail_msg">
> - Not needed in the importing module: change to nullptr<br class="gmail_msg">
<br class="gmail_msg">
</span>We don't have macros by default, right? You need some -gmacros flag I hope? I remember objecting to the massive debug info bloat when they were introduced, but was convinced by an argument along the lines of "it's-never-going-to-be-on-by-default".<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">No I haven't seen a case where this is non-null in my ThinLTO testing, but it seemed safe to do for completeness.</div></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="m_-4457950798788683949gmail- gmail_msg"><br class="gmail_msg">
> c) List of global variables<br class="gmail_msg">
> - Only needed if we have imported the corresponding global variable definition. Since we currently don't import any global variable definitions (we should assert that there aren't any in the import list so this doesn't get stale), we can change this to nullptr.<br class="gmail_msg">
<br class="gmail_msg">
</span>Why does this still exist? Can't we delete this list in all modes, since GlobalValues reference their own DIGlobalVariables directly?<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Peter, can you answer this question? I looked back at the old thread and ISTR that there were some cases where the reference from the CU was needed but don't remember the details.</div></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="m_-4457950798788683949gmail- gmail_msg"><br class="gmail_msg">
> d) List of imported entities<br class="gmail_msg">
> - For now need to import those that have a DILocalScope (and drop others from the imported entities list on the imported CU). David had some ideas on restructuring the way these are referenced, but for now we conservatively need to keep those that may be from functions, any that are from functions not actually imported will not be emitted into the object file anyway.<br class="gmail_msg">
<br class="gmail_msg">
</span>I'd rather just restructure these if we can.<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">That sounds like a good long-term solution. For for the short term what I did was incredibly simple. If it has a significant impact (haven't measured this one independently), I think the short-term fix would be good in the meantime. David can probably provide more details on what needs to be done to fix this longer term.</div></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="m_-4457950798788683949gmail- gmail_msg"><br class="gmail_msg">
> e) List of retained types<br class="gmail_msg">
> - Leave as-is but import DICompositeTypes as type declarations. This one David thought would need to be under an option because of lldb's assumption that the DWARF match the Clang AST (I think I am stating that right, correct me if not!).<br class="gmail_msg">
<br class="gmail_msg">
</span>How many of these exist? I expect this list to be almost always empty. If it's not, why not? (Did I fail to push the commit to Clang that stopped adding all C++ types here??) Can we somehow prune the list?<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">It seems that there are quite a lot. Just doing this caused a huge reduction on sizes. E.g. on Chromium, importing DICompositeType as type decls alone dropped the aggregate .o size increase with -g2 over plain -O2 from 5.2x (current ThinLTO) to 1.7x.</div></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br class="gmail_msg">
I'm concerned that this is not a particularly fast thing to do.<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">In what way?</div></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br class="gmail_msg">
I'm also worried that this would cause major debug info quality degradation on Darwin (defer to Adrian on that...). I'd rather leave it unoptimized unless we're sure we need to do something here.<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Maybe this is the issue David was referring to about potentially needing to put this under an option to disable for lldb. For us apparently it is not an issue.</div></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br class="gmail_msg">
Also, why do you need this for -flto=thin? Why not just nullptr?<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Meaning never import retained types? I think we need the type decls at least - David?</div></div></div></div></div></blockquote><div><br></div><div>I believe Duncan's right here, and I was mistaken - we may be able to just null out the retained types list.<br><br>I'd be curious what's in there that your change makes such a big difference - now that Duncan's corrected my misunderstanding/outdated info about what's in the retained types list.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br class="gmail_msg">
> Implementation:<br class="gmail_msg">
<br class="gmail_msg">
Generally, I'd rather see the direction of explicitly building new DICompileUnits and linking in the correct/necessary arguments, like the IRLinker explicitly builds new llvm::Functions. Ideally, we'd only have to explicitly deal with DICompileUnit (one reason that I'm concerned about (e) above), which we can find through !<a href="http://llvm.dbg.cu" rel="noreferrer" class="gmail_msg" target="_blank">llvm.dbg.cu</a>.<br class="gmail_msg">
<div class="m_-4457950798788683949gmail-HOEnZb gmail_msg"><div class="m_-4457950798788683949gmail-h5 gmail_msg"><br class="gmail_msg">
> a)-d) (enums/macros/global variables/imported entities):<br class="gmail_msg">
><br class="gmail_msg">
> For a-d I have a simple solution in the IRLinker. At the very start of IRLinking in a module, if it is being linked in for function importing, I invoke a function that does the handling (i.e. from the IRLinker constructor).<br class="gmail_msg">
><br class="gmail_msg">
> This routine handles a-c by pre-populating the ValueMap's MDMap entry for those Metadata* (e.g. the RawEnumTypes Metadata*) with nullptr, so metadata mapping automatically makes them nullptr on the imported DICompileUnit.<br class="gmail_msg">
><br class="gmail_msg">
> For d, this routine walks the imported entities on the source CU and builds a SmallVector of those with local scopes. It then invokes replaceImportedEntities on the source CU to replace it with the new list (essentially dropping those with non-local scopes), and again the subsequent metadata mapping just works.<br class="gmail_msg">
><br class="gmail_msg">
> e) (retained types):<br class="gmail_msg">
><br class="gmail_msg">
> For e, changing the imported DICompisiteType to type declarations, I am having some issues. I prototyped this by doing it in the BitcodeReader. I passed in a new flag indicating that we are parsing a module for function importing. Then when parsing a METADATA_COMPOSITE_TYPE, if we are importing a module I change the calls to buildODRType and GET_OR_DISTINCT to instead create a type declaration:<br class="gmail_msg">
> - pass in flags Flags|DINode::FlagFwdDecl<br class="gmail_msg">
> - pass in nullptr for BaseType, Elements, VtableHolder, TemplateParams<br class="gmail_msg">
> - pass in 0 for OffsetInBits<br class="gmail_msg">
><br class="gmail_msg">
> Note that buildODRType will not mutate any existing DICompisiteType for that identifier found in the DITypeMap to a type declaration (FlagFwdDecl) though. This is good since we are sharing the DITypeMap with the original (destination) module, and we don't want to change any type definitions on the existing destination (importing) module to be type declarations when the same type is also in the source module we are about to import.<br class="gmail_msg">
><br class="gmail_msg">
> When cleaning this up, I initially tried mutating the types on the source module at the start of IRLinking of imported modules. I did this by adding a new DICompositeType function to force convert an existing type definition to a type declaration (since the bitcode reader already would have created a type definition when parsing the imported source module, and as I noted above it wasn't allowed to be mutated to a declaration after that point). However, this is wrong since it ended up changing type definitions that were also used by the original destination/importing module to type declarations if they were also used in the source module (and therefore shared a DITypeMap entry). To get the forced mutation to a type decl to work here, I would somehow need to detect when a composite type on the source module was *not* also used by the original destination module. The only way I came up with off the top of my head was to also do a DebugInfoFinder::processModule on the dest module, and subtract the resulting types() from those I found when finding types on the source module I'm about to import, and only force-convert the remaining ones to type decls.<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> Interested in feedback on any of the above, and in particular on the cleanest way to create type declarations for imported types.<br class="gmail_msg">
><br class="gmail_msg">
> Thanks!<br class="gmail_msg">
> Teresa<br class="gmail_msg">
><br class="gmail_msg">
> --<br class="gmail_msg">
> Teresa Johnson | Software Engineer | <a href="mailto:tejohnson@google.com" class="gmail_msg" target="_blank">tejohnson@google.com</a> | <a href="tel:408-460-2413" value="+14084602413" class="gmail_msg" target="_blank">408-460-2413</a><br class="gmail_msg">
<br class="gmail_msg">
</div></div></blockquote></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><br class="gmail_msg"><br clear="all" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div>-- <br class="gmail_msg"><div class="m_-4457950798788683949gmail_signature gmail_msg"><span style="font-family:times;font-size:medium" class="gmail_msg"><table cellspacing="0" cellpadding="0" class="gmail_msg"><tbody class="gmail_msg"><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small" class="gmail_msg"><td nowrap style="border-top:2px solid rgb(213,15,37)" class="gmail_msg">Teresa Johnson |</td><td nowrap style="border-top:2px solid rgb(51,105,232)" class="gmail_msg"> Software Engineer |</td><td nowrap style="border-top:2px solid rgb(0,153,57)" class="gmail_msg"> <a href="mailto:tejohnson@google.com" class="gmail_msg" target="_blank">tejohnson@google.com</a> |</td><td nowrap style="border-top:2px solid rgb(238,178,17)" class="gmail_msg"> <a href="tel:(408)%20460-2413" value="+14084602413" class="gmail_msg" target="_blank">408-460-2413</a></td></tr></tbody></table></span></div>
</div></div></div></blockquote></div></div>