<div dir="ltr">Trying to wrap my brain around this, so a few questions below. =)<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 15, 2016 at 10:54 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Branching off from a discussion of improvements to DIGlobalVariable representations that Adrian's working on - got me thinking about related changes that have already been made to DISubprogram.<br><br>To reduce duplicate debug info when things like linkonce_odr functions were deduplicated in LTO linking, the relationship between a CU and DISubprogram was inverted (instead of a CU maintaining a list of subprograms, subprograms specify which CU they come from - and the llvm::Function references the DISubprogram, so if the llvm::Function goes away, so does the associated DISubprogram)<br><br>I'm not sure if this caused a regression, but at least seems to miss a possible improvement:<br><br>During IR linking (for LTO, ThinLTO, etc) these distinct DISubprogram definitions (& their CU link, even if they weren't marked 'distinct', the CU link would cause them to effectively be so) remain separate - this means that inlined versions in one CU don't refer to an existing subprogram definition in another CU.<br><br>To demonstrate:<br>inl.h:<br><div>void f1();</div><div>inline __attribute__((always_inline)) void f2() {</div><div>  f1();</div><div>}<br>inl1.cpp:<br><div>#include "inl.h"</div><div>void c1() {</div><div>  f2();</div><div>}<br>inl2.cpp:<br><div>#include "inl.h"</div><div>void c2() {</div><div>  f2();</div><div>}<br><br>Compile to IR, llvm-link the result. The DWARF you get is basically the same as the DWARF you'd get without linking:<br><br>DW_TAG_compile_unit<br>  DW_AT_name "inl1.cpp"<br>  DW_TAG_subprogram #0<br>    DW_AT_name "f2"</div></div></div><div>  DW_TAG_subprogram<br>    DW_AT_name "c1"<br>    DW_TAG_inlined_subroutine<br>      DW_TAG_abstract_origin #0 "f2"<div><div><div>DW_TAG_compile_unit<br>  DW_AT_name "inl2.cpp"<br>  DW_TAG_subprogram #1<br>    DW_AT_name "f2"</div></div></div><div>  DW_TAG_subprogram<br>    DW_AT_name "c2"<br>    DW_TAG_inlined_subroutine<br>      DW_TAG_abstract_origin #1 "f2"<br><br>Instead of something more like this:<br><br><div><div><div>DW_TAG_compile_unit<br>  DW_AT_name "inl1.cpp"<br>  DW_TAG_subprogram #0<br>    DW_AT_name "f2"</div></div></div><div>  DW_TAG_subprogram<br>    DW_AT_name "c1"<br>    DW_TAG_inlined_subroutine<br>      DW_TAG_abstract_origin #0 "f2"<div><div><div>DW_TAG_compile_unit<br>  DW_AT_name "inl2.cpp"</div></div></div><div>  DW_TAG_subprogram<br>    DW_AT_name "c2"<br>    DW_TAG_inlined_subroutine<br>      DW_TAG_abstract_origin #0 "f2"</div></div></div><br class="m_-6809783484898340448inbox-inbox-Apple-interchange-newline"></div>(note that only one abstract definition of f2 is produced here)<br></div></blockquote><div><br></div><div>I think I understand what you are saying. Essentially, having the SP->CU link allows the SP to be deduplicated when multiple *outline* copies of the corresponding function are deduplicated. But not when the multiple copies are inlined, as it looks like we need all the copies, right?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br>Any thoughts? I imagine this is probably worth a reasonable amount of savings in an optimized build. Not huge, but not nothing. (probably not the top of anyone's list though, I realize)<br><br>Should we remove the CU link from a non-internal linkage subprogram (& this may have an effect on the GV representation issue originally being discussed) and just emit it into whichever CU happens to need it first?<br></div></blockquote><div><br></div><div>I can see how this would be done in LTO where the compiler has full visibility. For ThinLTO presumably we would need to do some index-based marking? Can we at least do something when we import an inlined SP and drop it since we know it is defined elsewhere?</div><div><br></div><div>Thanks,</div><div>Teresa</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br>This might be slightly sub-optimal, due to, say, the namespace being foreign to that CU. But it's how we do types currently, I think? So at least it'd be consistent and probably cheap enough/better.</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><span style="font-family:Times;font-size:medium"><table cellspacing="0" cellpadding="0"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Teresa Johnson |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a> |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"> 408-460-2413</td></tr></tbody></table></span></div>
</div></div>