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 Jan 02 2014 at 12:10:42 PM, Adrian Prantl <aprantl at apple.com> wrote:

>
> 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?
>

None that spring immediately to my mind.


> I think it would make sense to keep the -flimit-debug-info name as the
> umbrella flag name;


While I realize I disagreed with you about this earlier in the thread, I've
mostly come around here, in the sense that I hope most users using this
flag are using it because what they really want is "I'm compiling part of
my project with debug info enabled and can't rely on other compile units to
have debug info".

Though there's probably some users with -fno-limit-debug-info because it
was broken...


> it’s a generic term and our users are already vaguely familiar with it.


I think it's too generic and our users may only be familiar with it when it
hurt them, without knowing why (without knowing whether it was a bug, for
example).


> 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.
>

Mostly agree.


> 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
>

I'd still be inclined to introduce a better name for -flimit-debug-info as
an alias that we document going forward. Possibly in the affirmative
"-fstandalone-debug" (ie: emit all the relevant debug info as if this
translation unit were standalone/had no reliance on other object files).
Open to other names. Or perhaps this is the right place to reuse GCC's
-femit-class-debug-always?

Personally I'm OK stopping there and not providing fine-grained access to
the two separate optimizations until we have a use-case.

If someone really wants subflags (Chandler mentioned a preference, but I
assume it's not binding/authoritative) I'm happy to bikeshed their names.

-femit-class-debug-on-complete-types ? I don't know - it'll be verbose no
matter how we phrase it.

-femit-class-debug-on-dynamic-types


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

Eric mentioned that on a cursory inspection of GCC, this flag controlled
other things as well as the vtable optimization and he might not be
comfortable using that name while not implementing the same semantics as
GCC.


>
> 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?
>

Possibly, at some point.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140103/ddc413bf/attachment.html>