+Adrian so he can read the backstory/previous thread on this same topic Adrian - best to start from here so we've all got the previous context to continue this conversation if it needs to be continued.
On Tue, Oct 15, 2013 at 11:25 AM, Chandler Carruth <[email protected]>wrote: > > On Tue, Oct 15, 2013 at 10:13 AM, David Blaikie <[email protected]>wrote: > >> I think it is reasonable to add a similar flag for clang: >>> 1> gcc has a flag to turn this off, I would imagine there are debuggers >>> out there that don't support this kind of extra searching for types. >>> 2> The possibility that the actual use where we would emit the class def >>> could get stripped >>> >>> What do you think? >>> >> >> Personally I'm OK implementing the exact spelling of GCC's flag purely >> for compatibility. Whether or not it's a great idea to disable it seems >> somewhat less important. >> >> If we wanted to justify it - yes, you're right, you could have a program >> where only some translation units are built with debug info (for whatever >> reason) in which case this optimization (and the core -flimit-debug-info >> optimization) would not be sound. >> >> I would still suggest, as Eric was driving at, that if you /do/ have >> performance problems due to this change, you investigate those issues >> rather than simply disabling the optimization. It's a rather valuable size >> improvement you probably don't want to disable. >> > > Manman, I really don't like the direction this is going. > > There are essentially three ways this should proceed: > > 1) You have a real problem with this behavior, and can provide a clear, > and easily understood explanation for what behavior you need. Without this, > it doesn't make sense for the open source project to try to fuzzily match > some unstated set of expectations for the debug info produced. > > 2) You don't have a real problem, but are worried somewhere someone may > run into this issue. While this level of concern is admirable, I think the > only way we can proceed is to assume that in the absence of concrete user > reports of a problem, the problem doesn't exist. Otherwise, even if a > problem does manifest, it will be different from our assumptions and we > will have planned poorly. > > 3) You have a real problem with this behavior, but cannot (for many > legitimate reasons perhaps) discuss exactly what the situation is or why > that problem exists, or what precise behavior is needed. In this case, I > think the only reasonable approach is for you to maintain an internal patch > where all the maintainers of that patch at least have the context to > understand why it exists and what it is trying to accomplish. > > > Does that make sense? Let's not go down the path of more flags and more > varied behavior unless we have #1. > > -Chandler >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
