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 Wednesday, December 25, 2013 10:49:08 PM, Chandler Carruth <
chandlerc at google.com> wrote:

On Tue, Dec 24, 2013 at 2:57 PM, dblaikie@
<dblaikie at gmail.com>gmail.com<dblaikie at gmail.com><
dblaikie@ <dblaikie at gmail.com>gmail.com <dblaikie at gmail.com>> wrote:

I hereby propose to go with David’s suggestion above to add an independent
-femit-class-debug-always option to clang that controls this behavior. I’m
also volunteering to implement it.

  1) Eric mentioned some concerns that this flag does something else in GCC
- implementing subtly different semantics for the same flag might not be
ideal

 It would seem better to tie this flag to the same thing that the vtable is
tied to? (key functions?) Or if the only common factor is the vtable
itself, just make it do what it says on the tin:
-femit-class-debug-info-with-vtable, and it defaults on where we can use
this optimization



The latter. It really isn't powered by key functions - just vtable
emission. Its just more powerful in the presence of key functions.





2) a broader flag that expresses the "assume I'm only building this
translation unit with debug info" might be a more useful feature - this
would encompass -flimit-debug-info as well (sort of bringing us full circle
to your original proposal) but potentially renaming it to be more
descriptive/actionable for users, and future proof for when we find other
reasons to omit debug info because we know it'll be elsewhere. Though I'm
still not 100% sure of bundling these two things together. It might be the
right thing, but I'm just not sure (mostly I'm not sure if the current
-flimit-debug-info behavior is perfectly correct/sane - we'd need to check
the GDB 7.5 failures that  occur when this flag is enabled, just to ensure
that there aren't any fundamental bugs in the flag that mean even
full-debug-builds would want to disable that optimization without disabling
the vtable opt)

 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?

-David

My 2 cents.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131226/bda96463/attachment.html>