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

[David Blaikie]

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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140217/7cda2424/attachment.html>