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

[dblaikie at gmail.com]

On Thu Dec 26 2013 at 11:37:14 AM, Chandler Carruth <chandlerc at google.com>
wrote:

>
> On Thu, Dec 26, 2013 at 2:09 PM, dblaikie at gmail.com <dblaikie at gmail.com>wrote:
>
> I think this potentially makes sense as a nice and descriptive umbrella
> flag. I like the idea of a best-effort flag that switches the debug info
> emission to compensate for partial compilation with debug info. I suspect
> we'll end up with more than 2 specific features we want to toggle for this
> purpose, and so having an umbrella flag makes a lot of sense to me
>
>
>
> Do you see any value in having the specific flags? I was
> considering/suggesting having the broad flag without the specific ones at
> all. I can't think of any use for the specific ones off-hand. Does someone
> have one/some?
>
>
> Mostly testing,
>

Testing the difference between the current -flimit-debug-info and the
vtable-based optimization is pretty easy. Mostly just adding a key function
(not because it's necessary for the optimization, but because it makes it
very clear which TU the class definition debug info is expected in) or not.


> regression finding, and documentation for other developers. Essentially, I
> think somewhat "internal" flags to control the details makes sense even
> though I wouldn't really advertise them to users.
>

Fair enough - I'd err slightly towards not bothering with the intermediate
flags but I'm open to having the finer-grained flags - up to whoever ends
up implementing this.

I would slightly prefer/suggest that we figure out the umbrella flag name
and alias -flimit-debug-info to that, then choose new flags for the finer
grained features, if we have them at all. (-flimit-debug-info is
insufficiently descriptive for the fine grained flag and at least might be
vaguely used by people who already realized -flimit-debug-info's
optimizations aren't good for their use case and for which the vtable
optimization will be similarly problematic)

The only drawback is that -flimit-debug-info has a legacy of being... not
good. It isn't really bad anymore since I fixed it by leveraging Clang's
"Requires Complete Type" status but some people might still be disabling it
for those historical reasons & would then loose a fairly robust size
optimization by accident.

(though we could probably do an analysis on -flimit-debug-info and see what
the size win really is since it's been fixed - maybe it's not even worth
keeping and we could just make the flag a no-op instead)

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131227/4e004dc8/attachment.html>