<div dir="ltr">So, a while back I had started working on a debug info type optimization (similar to the vtable optimization that avoids emitting type information for dynamic classes except in the TUs that emit the vtable (thus drastically reducing debug info size)) because I'd mistaken GCC's vtable optimization for this other one.<br>
<br>The basic idea is that, since any program that contains an explicit template instantiation declaration and ODR uses that type must also have an explicit template instantiation definition - we could leverage this to avoid emitting the full debug info for that type in the TUs that contain the explicit declaration and forcibly emit the type where the explicit definition is.<br>
<br>Easy.<br><br>Except there's a wrinkle. We need to interoperate with GCC's debug info (for things like the standard library). This means we can't make stronger assumptions about where the debug info will be emitted than GCC will provide. <br>
<br>For example:<br><br>template<typename T> struct foo { int i; }<br>template struct foo<int>;<br><br>Doesn't cause GCC to emit debug info for foo<int>. But if you add a "void mem() { }" to 'foo', then it does (since the definition of the foo<int>::mem function has to be emitted, along with the debug info for that and thus the debug info for its enclosing class... ).<br>
<br>So, what I'd like to be able to do is come up with some conservative test for "will this explicit template instantiation actually cause GCC to emit the debug info for the type" one such "sufficient by not necessarily necessary" Condition for this would be "are there any member function definitions prior to the explicit instantiation decl". But I'm having trouble writing that test - my cursory attempt to walk the methods of the CXXRecordDecl and test that they were defined failed.<br>
<br>I'm guessing this failed because Clang isn't instantiating the definitions of the member functions because it doesn't need to (though it is allowed to, well, for the inline ones - there could be out of line definitions I could leverage here too)?<br>
<br>Is there a good/better/existing way I could write this test?<br><br>[if/when we implement this I'd still like to more aggressively emit the definition in the presence of even trivial explicit instantiation definitions where GCC currently doesn't - so that maybe in the future we can remove this extra check and just rely on the decl and def to do this more aggressively]</div>