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). >
Huh, neat. Didn't see that when I looked :) Given the description it sounds pretty inflationary though. :) -eric >> >> -eric >> >> >> > Manman >> > >> >> >> >> -eric >> >> >> >> >>> >> >> >>> >> >> >>>> >> >> >>>> Is it reasonable for this commit to be enabled only for >> >> >>>> limit-debug-info, when no-limit-debug-info is on, we don't see >> >> >>>> effects of >> >> >>>> this patch? >> >> >>> >> >> >>> >> >> >>> GCC does this by default, at least on Linux - I haven't tested on >> >> >>> MacOS. >> >> >>> I would guess it does so there too (but as you point out, there are >> >> >>> different tradeoffs there, so I might be wrong). >> >> >>> >> >> >>> I'd like to understand the performance tradeoff to justify such a >> >> >>> large >> >> >>> regression in debug info size (it's worth about ~20% on Clang/LLVM >> >> >>> based on >> >> >>> my experiments). >> >> >> >> >> >> >> >> >> Our default is -limit-debug-info, so this will be on by default. I >> >> >> was >> >> >> asking whether we should guard this so when people use >> >> >> "-fno-limit-debug-info", they will get the definition. >> >> > >> >> > >> >> > -flimit-debug-info has some relatively rough heuristics that aren't >> >> > as >> >> > high >> >> > confidence as the vtable based debug info emission mechanism, I'm not >> >> > sure >> >> > we want to group these together. (eg: it seems likely that a user >> >> > might >> >> > have >> >> > issues with the minimization caused by -flimit-debug-info and want to >> >> > turn >> >> > it off, if in doing so they also turn off the vtable based, >> >> > higher-confidence optimization, that would be unfortunate) >> >> > >> >> > - David >> >> > >> >> >> >> >> >> >> >> >> Thanks, >> >> >> Manman >> >> >> >> >> >>> >> >> >>> >> >> >>> >> >> >>> - David >> >> >>> >> >> >>>> >> >> >>>> >> >> >>>> Thanks, >> >> >>>> Manman >> >> >>>> >> >> > >> >> > >> >> > _______________________________________________ >> >> > cfe-commits mailing list >> >> > [email protected] >> >> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >> >> > >> > >> > > > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
