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

[Eric Christopher]

On Fri, Oct 11, 2013 at 3:49 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
>
>
> 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-always Instead 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).
>

Huh, neat. Didn't see that when I looked :)

Given the description it sounds pretty inflationary though. :)

-eric

>>
>> -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
>> >> >
>> >
>> >
>
>