<br><br><div>On Thu Jan 02 2014 at 12:10:42 PM, Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Dec 27, 2013, at 10:46, <a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a> wrote:<br>
<br>
> On Thu Dec 26 2013 at 11:37:14 AM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>><br>
> wrote:<br>
><br>
> ><br>
> > On Thu, Dec 26, 2013 at 2:09 PM, <a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a> <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>>wrote:<br>
> ><br>
> > I think this potentially makes sense as a nice and descriptive umbrella<br>
> > flag. I like the idea of a best-effort flag that switches the debug info<br>
> > emission to compensate for partial compilation with debug info. I suspect<br>
> > we'll end up with more than 2 specific features we want to toggle for this<br>
> > purpose, and so having an umbrella flag makes a lot of sense to me<br>
> ><br>
> ><br>
> ><br>
> > Do you see any value in having the specific flags? I was<br>
> > considering/suggesting having the broad flag without the specific ones at<br>
> > all. I can't think of any use for the specific ones off-hand. Does someone<br>
> > have one/some?<br>
> ><br>
> ><br>
> > Mostly testing,<br>
> ><br>
><br>
> Testing the difference between the current -flimit-debug-info and the<br>
> vtable-based optimization is pretty easy. Mostly just adding a key function<br>
> (not because it's necessary for the optimization, but because it makes it<br>
> very clear which TU the class definition debug info is expected in) or not.<br>
><br>
><br>
> > regression finding, and documentation for other developers. Essentially, I<br>
> > think somewhat "internal" flags to control the details makes sense even<br>
> > though I wouldn't really advertise them to users.<br>
> ><br>
><br>
> Fair enough - I'd err slightly towards not bothering with the intermediate<br>
> flags but I'm open to having the finer-grained flags - up to whoever ends<br>
> up implementing this.<br>
That would be me :-)<br>
><br>
> I would slightly prefer/suggest that we figure out the umbrella flag name<br>
> and alias -flimit-debug-info to that, then choose new flags for the finer<br>
> grained features, if we have them at all. (-flimit-debug-info is<br>
> insufficiently descriptive for the fine grained flag and at least might be<br>
> vaguely used by people who already realized -flimit-debug-info's<br>
> optimizations aren't good for their use case and for which the vtable<br>
> optimization will be similarly problematic)<br>
><br>
> The only drawback is that -flimit-debug-info has a legacy of being... not<br>
> good. It isn't really bad anymore since I fixed it by leveraging Clang's<br>
> "Requires Complete Type" status but some people might still be disabling it<br>
> for those historical reasons & would then loose a fairly robust size<br>
> optimization by accident.<br>
<br>
Let’s attempt to summarize our options here:<br>
<br>
Are there any flags that control the debug info “level” other than vtable optimization and -flimit-debug-info?<br></blockquote><div><br></div><div>None that spring immediately to my mind.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think it would make sense to keep the -flimit-debug-info name as the umbrella flag name;</blockquote><div><br></div><div>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".<br>
<br>Though there's probably some users with -fno-limit-debug-info because it was broken... </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> it’s a generic term and our users are already vaguely familiar with it. </blockquote>
<div><br>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).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br></blockquote><div><br></div>
<div>Mostly agree.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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)<br>

<br>
1) -flimit-debug-info<br></blockquote><div><br></div><div>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?<br>
<br>Personally I'm OK stopping there and not providing fine-grained access to the two separate optimizations until we have a use-case.<br><br>If someone really wants subflags (Chandler mentioned a preference, but I assume it's not binding/authoritative) I'm happy to bikeshed their names. <br>
<br>-femit-class-debug-on-complete-types ? I don't know - it'll be verbose no matter how we phrase it.<br><br>-femit-class-debug-on-dynamic-types</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

    |<br>
    +- -fno-forward-decl-debug-types (the old limit-debug-info)<br>
    |<br>
    +- -fno-emit-class-debug-always (the new flag)<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If we don’t want to change the meaning of limited debug info, we could have<br>
<br>
2) -fpartial-debug-info (a new umbrella flag)<br>
    |<br>
    +- -flimit-debug-info (unchanged)<br>
    |<br>
    +- -fno-emit-class-debug-always (idem)<br>
<br>
I’m leaning slightly towards option 1.<br>
<br>
> (though we could probably do an analysis on -flimit-debug-info and see what<br>
> the size win really is since it's been fixed - maybe it's not even worth<br>
> keeping and we could just make the flag a no-op instead)<br>
Did I hear somebody volunteering?<br></blockquote><div><br>Possibly, at some point. </div>