<br><br><div>On Thu Dec 26 2013 at 11:37:14 AM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><br><div>On Thu, Dec 26, 2013 at 2:09 PM, <a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a> <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br>

<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><blockquote><p dir="ltr">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</p>



</blockquote>
<br><br></div>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?<br>

</blockquote></div><br></div></div><div dir="ltr"><div>Mostly testing, </div></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.</div>
</div></blockquote><div><br>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.<br><br>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)<br>
<br>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.<br>
<br>(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)<br>
<br>- David </div>