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
