<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 1, 2015 at 5:29 PM, Robinson, Paul <span dir="ltr"><<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank">Paul_Robinson@playstation.sony.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We were doing some size analysis and noticed some ridiculous numbers<br>
related to debug-info size.  Investigation showed that essentially all<br>
of the bloat came from DW_TAG_imported_declaration pointing to<br>
DW_TAG_subprogram and the associated DW_TAG_formal_parameter DIEs.<br>
We tracked this to r222220, which basically caused every 'using' decl<br>
of a function or variable to have a forward declaration emitted to the<br>
DWARF, whether or not that 'using' decl itself was used in the CU.<br>
<br>
#include <stdlib.h><br>
using ::abort<br>
<br>
In Clang 3.5, this produces a pretty minimal .debug_info section (just<br>
the DW_TAG_compile_unit).<br>
In Clang 3.6, we see an additional DW_TAG_subprogram for abort() and then<br>
a DW_TAG_imported_declaration pointing to that declaration.<br>
<br>
#include <cstdlib><br>
<br>
on Linux, Clang 3.5 wrote a .debug_info of 185 bytes, 3.6 was 1458.<br>
<br>
Multiply this by more headers and again by hundreds to thousands<br>
of modules and pretty soon you're talking multiple megabytes.<br>
Getting away from the benchmarks, a real game saw .debug_info increase<br>
by 13% (6 MB).<br></blockquote><div><br>Did you happen to go back further to my original implementation of DW_TAG_imported_module too? I imagine it'd have a similar issue, though perhaps there are fewer cases of a large number of using directives compared to the large number of using declarations in your real world example.<br><br>In any case, I believe there were a few issues when I originally implemented both imported_module and imported_declaration:<br><br>We don't keep track of whether these imported entities are used via the imported name or not, so we can't keep track of that. So I conservatively emitted them all - I wouldn't be entirely averse to only emitting those that are referenced, but it'd be a Clang change to keep track of how the names were referenced (or even just keep track of the fact that the original entity was referenced, then emit any using declarations/directives that pertain to it - and keep track of those so we could do that when needed).<br><br>Emitting these only where the entity is defined isn't going to work - as Frederick showed, users may have using declarations/directives for foreign entities.<br><br>Long story short: There's some improvements that could be made here, but they're a fair bit of work to keep track of more info in Clang, so far as I know/recall.<br><br>- David<br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
r222220 basically causes a 'using' declaration of a function or global<br>
variable to conjure up a forward declaration, if we haven't already<br>
seen a declaration or definition.  The commentary talks about how this<br>
will be RAUW'd later on.  But I'm not sure what motivated this in the<br>
first place, and it clearly can have a huge adverse effect.<br>
<br>
I don't mind having a DW_TAG_imported_declaration for something that<br>
actually gets used in the CU, but a 'using' declaration all by itself<br>
should not count as "used" for purposes of emitting debug info.<br>
<br>
Can somebody describe how these extra forward declarations fit into<br>
the Grand Scheme of Things in a beneficial way, and can we do something<br>
about unused 'using' declarations?<br>
<br>
Given how the patch works, it looks we can just short-circuit the<br>
creation of these forward declarations with no harm done, but I have to<br>
wonder whether we're shooting ourselves in the foot in some situation<br>
that isn't immediately obvious.<br>
<br>
Thanks,<br>
--paulr<br>
<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div></div>