The option as given from gcc is quite a bit more to the other side than just disabling this optimization and I'd prefer not to implement options in slightly incompatible ways.
-eric On Tue, Oct 15, 2013 at 10:46 AM, Manman Ren <[email protected]> wrote: > > > > On Tue, Oct 15, 2013 at 10:13 AM, David Blaikie <[email protected]> wrote: >> >> >> >> >> On Tue, Oct 15, 2013 at 10:09 AM, Manman Ren <[email protected]> wrote: >>> >>> >>> >>> >>> On Fri, Oct 11, 2013 at 3:49 PM, David Blaikie <[email protected]> >>> wrote: >>>> >>>> >>>> >>>> >>>> On Fri, Oct 11, 2013 at 3:46 PM, Eric Christopher <[email protected]> >>>> wrote: >>>>> >>>>> >> The accelerator table should help - since it only has definitions >>>>> >> and >>>>> >> it's on by default for darwin. What's up that's causing a >>>>> >> performance >>>>> >> degradation? >>>>> > >>>>> > >>>>> > I don't have numbers right now, in theory extra search means slower >>>>> > response >>>>> > (maybe insignificant). >>>>> > >>>>> >>>>> Probably insignificant here given the debugger is using the >>>>> accelerator tables. I'd need to know what other use you're thinking >>>>> about to determine whether or not the slowdown could be damaging >>>>> otherwise. >>>>> >>>>> >>>>> > I was asking whether it is worthwhile to guard this change with a >>>>> > flag. If >>>>> > -no-limit-debug-info is not the right flag, >>>>> > is it reasonable to have a different flag for this? Does gcc has a >>>>> > flag to >>>>> > turn this off? >>>>> > >>>>> >>>>> Nope. >>>> >>>> >>>> I believe it does, actually: >>>> >>>> -femit-class-debug-always Instead of emitting debugging information for >>>> a C++ class in only one object file, emit it in all object files using the >>>> class. This option should be used only with debuggers that are unable to >>>> handle the way GCC normally emits debugging information for classes because >>>> using this option increases the size of debugging information by as much as >>>> a factor of two. >>>> >>>> >>>> It's not a precise description of the feature, but it certainly seems to >>>> correlate with the behavior. >>>> >>>> >>>> struct foo { >>>> virtual ~foo(); >>>> }; >>>> >>>> int main() { >>>> foo f; >>>> } >>>> >>>> Without the flag, a declaration of 'foo' is emitted, with the flag a >>>> definition of 'foo' is emitted (by GCC ToT). >>> >>> >>> Thanks for the information! >>> >>> 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. > > > Yes, we will work on fixing issues. I know this optimization reduces the > debug info size a lot, so disabling the optimization is only a temporary > solution. > > Manman > >> >> >> >> - David > > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
