r188739 - Revert "Revert "Revert "Revert "DebugInfo: Omit debug info for dynamic classes in TUs that do not have the vtable for that class""""

[David Blaikie]

On Tue, Dec 17, 2013 at 12:23 PM, Greg Clayton <gclayton at apple.com> wrote:

> >
> > >
> > > We do need to have the option to turn this optimization off;
> preferably we would make off the default for Darwin. Other platforms that
> use LLDB as their primary debugger may want to do the same thing.
> > >
> > > Is there no way to fix LLDB so it actually loads in the other dsyms
> and finds the full definition of the type? It would seem unfortunate to
> have such a bloated debug info format (not only for this optimization, but
> for the existing -flimit-debug-info optimizations and anything else we
> might think of in the future where we can ensure that some debug info is
> already availabel in another file).
> >
> > We can fix LLDB but at what cost? If we don't know where a "foo" base
> class comes from, should we start download _all_ debug info for _all_
> shared libraries until we find it? I don't really like that solution. I
> would like to see the full base class should always be there and would
> rather not have to use "-fno-limit-debug-info" which would make the debug
> info really really really bloated.
> >
> > Really really bloated?
> >
> > a) -flimit-debug-info is a more aggressive optimization than the vtable
> optimization - it will cause many pointer uses to emit only declarations
> and not definitions in the debug info. (it was even more aggressive before
> I fixed it 3 months ago - if you were using -flimit-debug-info prior to
> that then you're already far more tolerant to missing definitions than you
> realize)
>
> I was saying that using "-fno-limit-debug-info" should not try to cull
> _any_ debug info and would result in all types being emitted with complete
> definitions, no?
>

No - what you're describing is GCC's -gfull, which Clang does not currently
implement.

Here's the way things are:

Clang never emits types that are not referenced from some codegen'd
costruct. That means an inline function with no callers has no debug info
(& thus any types it uses (parameters, local variables, etc)aren't placed
in the debug info), for example. Any type that /is/ referenced by a
codegen'd construct will be emitted as a declaration if that's all that is
available in this translation unit, or a definition if one is provided
(even if the definition is provided after the use: struct foo; foo *f;
struct foo { }; )

-flimit-debug-info (the default) goes a step further than that - it doesn't
emit definitions, even if they're available in the source, if the type is
not used in such a way that the definition is required (using Clang's
"required to be complete" callback). So the above 'foo' example would not
produce a definition of 'foo', but this example would: "struct foo; foo *f;
struct foo { int i; }; void func() { i->i = 3; }"). The assumption being
that if the type is never dereferenced in this translation unit the
definition is not required and we can rely on the definition being provided
in whatever other translation unit actually does the dereferencing. This
feature was specifically requested/suggested by Chris Lattner, as far as
I'm aware. When Eric measured the first implementation of this I think he
recorded only a 2-3% savings. Since my improvements to this we haven't done
any size comparisons, so I'm not sure what it's worth.

The vtable optimization, like the limit-debug-info approach, uses a similar
(though stronger - because it relies on a language guarantee not just an
informal heuristic) approach to guarantee that some other translation unit
will contain the debug info for the type.


>
> >
> > b) -flimit-debug-info is worth, at a guess, somewhere between 1 and 5%.
> This vtable optimization is worth closer to 20%. That's /serious/ bloat to
> consider accepting.
>
> I don't consider bloat being something that helps us to completely define
> a type that is going to be use when debugging so we can show the entire
> type and its member variables to the user.


How do you know which types are going to be needed by the user? What about
types that are only declared but not defined in this translation unit?
("struct foo; foo *f;")


> Also to be able to call functions on the base class is helpful too for
> people evaluating expressions. So I do realize you guys consider this
> bloat, but this information to us is important for the debug info to be
> useful.


My suggestion is that if you cannot rely on other parts of the project to
be built with debug info then you are going to have some /very/ expensive
intermediate debug info. This is simply a warning - I can't stop you from
making that choice, but it seems to go against a lot of efforts you, us,
and everyone have been making to improve the quality (including the size)
of debug info.

& I'm still rather confused as to how this could be the correct general
approach because there will always be cases where one translation unit only
has access to a declaration of a type ("struct foo; foo *f;") - you must be
able to go looking for the definition of that type for many use cases.

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131217/4654df7a/attachment.html>