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]

The option as given from gcc is quite a bit more to the other side
than just disabling this optimization and I'd prefer not to implement
options in slightly incompatible ways.

-eric

On Tue, Oct 15, 2013 at 10:46 AM, Manman Ren <manman.ren at gmail.com> wrote:
>
>
>
> On Tue, Oct 15, 2013 at 10:13 AM, David Blaikie <dblaikie at gmail.com> wrote:
>>
>>
>>
>>
>> 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.
>
>
> Yes, we will work on fixing issues. I know this optimization reduces the
> debug info size a lot, so disabling the optimization is only a temporary
> solution.
>
> Manman
>
>>
>>
>>
>> - David
>
>