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]

+Adrian so he can read the backstory/previous thread on this same topic

Adrian - best to start from here so we've all got the previous context to
continue this conversation if it needs to be continued.


On Tue, Oct 15, 2013 at 11:25 AM, Chandler Carruth <chandlerc at google.com>wrote:

>
> On Tue, Oct 15, 2013 at 10:13 AM, David Blaikie <dblaikie at gmail.com>wrote:
>
>> 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.
>>
>
> Manman, I really don't like the direction this is going.
>
> There are essentially three ways this should proceed:
>
> 1) You have a real problem with this behavior, and can provide a clear,
> and easily understood explanation for what behavior you need. Without this,
> it doesn't make sense for the open source project to try to fuzzily match
> some unstated set of expectations for the debug info produced.
>
> 2) You don't have a real problem, but are worried somewhere someone may
> run into this issue. While this level of concern is admirable, I think the
> only way we can proceed is to assume that in the absence of concrete user
> reports of a problem, the problem doesn't exist. Otherwise, even if a
> problem does manifest, it will be different from our assumptions and we
> will have planned poorly.
>
> 3) You have a real problem with this behavior, but cannot (for many
> legitimate reasons perhaps) discuss exactly what the situation is or why
> that problem exists, or what precise behavior is needed. In this case, I
> think the only reasonable approach is for you to maintain an internal patch
> where all the maintainers of that patch at least have the context to
> understand why it exists and what it is trying to accomplish.
>
>
> Does that make sense? Let's not go down the path of more flags and more
> varied behavior unless we have #1.
>
> -Chandler
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131214/aba80559/attachment.html>