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, Oct 15, 2013 at 10:09 AM, Manman Ren <manman.ren at gmail.com> wrote:

>
>
>
> 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).
>>
>
> Thanks for the information!
>
> I think it is reasonable to add a similar flag for clang:
> 1> gcc has a flag to turn this off, I would imagine there are debuggers
> out there that don't support this kind of extra searching for types.
> 2> The possibility that the actual use where we would emit the class def
> could get stripped
>
> What do you think?
>

Personally I'm OK implementing the exact spelling of GCC's flag purely for
compatibility. Whether or not it's a great idea to disable it seems
somewhat less important.

If we wanted to justify it - yes, you're right, you could have a program
where only some translation units are built with debug info (for whatever
reason) in which case this optimization (and the core -flimit-debug-info
optimization) would not be sound.

I would still suggest, as Eric was driving at, that if you /do/ have
performance problems due to this change, you investigate those issues
rather than simply disabling the optimization. It's a rather valuable size
improvement you probably don't want to disable.

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