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

[Adrian Prantl]

On Dec 27, 2013, at 10:46, dblaikie at gmail.com wrote:

> 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.
That would be me :-)
> 
> 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.

Let’s attempt to summarize our options here:

Are there any flags that control the debug info “level” other than vtable optimization and -flimit-debug-info?

I think it would make sense to keep the -flimit-debug-info name as the umbrella flag name; it’s a generic term and our users are already vaguely familiar with it. On top of that, before last week, we didn’t even bother documenting what the flag does exactly anyway, so there is little harm in changing its semantics to cover additional fine-grained flags.

Then we could introduce a more descriptive name for what used to be -flimit-debug-info, e.g., -fno-forward-decl-debug-types (better suggestions are welcome)

1) -flimit-debug-info
    |
    +- -fno-forward-decl-debug-types (the old limit-debug-info)
    |
    +- -fno-emit-class-debug-always (the new flag)

If we don’t want to change the meaning of limited debug info, we could have

2) -fpartial-debug-info (a new umbrella flag)
    |
    +- -flimit-debug-info (unchanged)
    |
    +- -fno-emit-class-debug-always (idem)

I’m leaning slightly towards option 1.

> (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)
Did I hear somebody volunteering?

-- adrian