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. - David
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
