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

[Manman Ren]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131015/ae62f11a/attachment.html>