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 1:07 PM, Manman Ren <manman.ren at gmail.com> wrote:

>
>
>
> On Fri, Oct 11, 2013 at 12:57 PM, David Blaikie <dblaikie at gmail.com>wrote:
>
>>
>>
>>
>> On Fri, Oct 11, 2013 at 12:51 PM, Manman Ren <manman.ren at gmail.com>wrote:
>>
>>> Hi, David
>>>
>>> I just noticed this has great size reduction on xalan (a SPEC
>>> benchmark), thanks for the work.
>>> The number of MDNodes in a lto debug build decreased from 29M to 12M.
>>>
>>
>> Great - thanks for the stats.
>>
>>
>>>  This may degrade the debugger's speed since we are now emitting
>>> declarations instead of definitions, and the debugger will have to search
>>> for the definition.
>>>
>>
>> Perhaps. I suppose moreso on Apple platforms where debug info isn't
>> linked, so searching multiple object files' debug info could be more
>> costly. But do the accelerator tables handle this by making it easy to find
>> the object file with the definition?
>>
>>
>>> One example is building XercesWrapperNavigator.cpp with -O0 -g, we are
>>> now emitting a forward declaration for XercesDocumentWrapper.
>>> XercesWrapperNavigator has a member (m_d) pointing to
>>> XercesDocumentWrapper, and we call m_d->func() inside
>>> XercesWrapperNavigator.cpp.
>>>
>>
>> Do you have any evidence that this adversely affects debugger performance?
>>
> For our internal tool chains, we now have to perform a string search to
> find the definition. In theory, the extra search should make it slower.
>

It'd be really nice to quantify this.


> Yes, the accelerator table can help the search.
>
>
>>
>>
>>> 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
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131011/235b7905/attachment.html>