On Thu Dec 26 2013 at 11:37:14 AM, Chandler Carruth <[email protected]> wrote:
> > On Thu, Dec 26, 2013 at 2:09 PM, [email protected] <[email protected]>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. 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. (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) - David
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
