[cfe-dev] Debug Info type optimization based on explicit template instantiation decls/defs

["C. Bergström"]

On 02/17/14 04:20 PM, David Blaikie wrote:
> 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.
>
> 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.
>
> Easy.
>
> 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.
>
> For example:
>
> template<typename T> struct foo { int i; }
> template struct foo<int>;
>
> 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... ).
>
> 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.
>
> 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)?
>
> Is there a good/better/existing way I could write this test?
>
> [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]
I don't know if it fits your use case, but at the cost of flag 
proliferation - what about adding a flag to control this behavior?

1) How often is system STL compiled with debugging
2) Do users really mix gcc+clang in the wild that often? I can see this 
being the case for system level things, but for pure userland stuff I 
suspect they may build the whole stack with clang. (When/if they are 
using clang)

I'm biased and I doubt my vote counts for much, but I'd go for full 
optimizations without penalty either by default with a flag to turn it 
off or a flag which enables it. If I'm reading the above correctly - it 
would avoid any need to do complex "tests".