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 Fri, Oct 11, 2013 at 3:46 PM, Eric Christopher <echristo at gmail.com>wrote:

> >> The accelerator table should help - since it only has definitions and
> >> it's on by default for darwin. What's up that's causing a performance
> >> degradation?
> >
> >
> > I don't have numbers right now, in theory extra search means slower
> response
> > (maybe insignificant).
> >
>
> Probably insignificant here given the debugger is using the
> accelerator tables. I'd need to know what other use you're thinking
> about to determine whether or not the slowdown could be damaging
> otherwise.


> > I was asking whether it is worthwhile to guard this change with a flag.
> If
> > -no-limit-debug-info is not the right flag,
> > is it reasonable to have a different flag for this? Does gcc has a flag
> to
> > turn this off?
> >
>
> Nope.
>

I believe it does, actually:

-femit-class-debug-alwaysInstead of emitting debugging information for a
C++ class in only one object file, emit it in all object files using the
class. This option should be used only with debuggers that are unable to
handle the way GCC normally emits debugging information for classes because
using this option increases the size of debugging information by as much as
a factor of two.


It's not a precise description of the feature, but it certainly seems to
correlate with the behavior.


struct foo {
  virtual ~foo();
};

int main() {
  foo f;
}

Without the flag, a declaration of 'foo' is emitted, with the flag a
definition of 'foo' is emitted (by GCC ToT).


> -eric
>
>
> > Manman
> >
> >>
> >> -eric
> >>
> >> >>>
> >> >>>
> >> >>>>
> >> >>>> Is it reasonable for this commit to be enabled only for
> >> >>>> limit-debug-info, when no-limit-debug-info is on, we don't see
> >> >>>> effects of
> >> >>>> this patch?
> >> >>>
> >> >>>
> >> >>> GCC does this by default, at least on Linux - I haven't tested on
> >> >>> MacOS.
> >> >>> I would guess it does so there too (but as you point out, there are
> >> >>> different tradeoffs there, so I might be wrong).
> >> >>>
> >> >>>  I'd like to understand the performance tradeoff to justify such a
> >> >>> large
> >> >>> regression in debug info size (it's worth about ~20% on Clang/LLVM
> >> >>> based on
> >> >>> my experiments).
> >> >>
> >> >>
> >> >> Our default is -limit-debug-info, so this will be on by default. I
> was
> >> >> asking whether we should guard this so when people use
> >> >> "-fno-limit-debug-info", they will get the definition.
> >> >
> >> >
> >> > -flimit-debug-info has some relatively rough heuristics that aren't as
> >> > high
> >> > confidence as the vtable based debug info emission mechanism, I'm not
> >> > sure
> >> > we want to group these together. (eg: it seems likely that a user
> might
> >> > have
> >> > issues with the minimization caused by -flimit-debug-info and want to
> >> > turn
> >> > it off, if in doing so they also turn off the vtable based,
> >> > higher-confidence optimization, that would be unfortunate)
> >> >
> >> > - David
> >> >
> >> >>
> >> >>
> >> >> Thanks,
> >> >> Manman
> >> >>
> >> >>>
> >> >>>
> >> >>>
> >> >>> - David
> >> >>>
> >> >>>>
> >> >>>>
> >> >>>> Thanks,
> >> >>>> Manman
> >> >>>>
> >> >
> >> >
> >> > _______________________________________________
> >> > cfe-commits mailing list
> >> > cfe-commits at cs.uiuc.edu
> >> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131011/91244c49/attachment.html>