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

[Chandler Carruth]

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/20131015/cd11e970/attachment.html>