On Fri, Oct 11, 2013 at 1:07 PM, Manman Ren <[email protected]> wrote:
> > > > On Fri, Oct 11, 2013 at 12:57 PM, David Blaikie <[email protected]>wrote: > >> >> >> >> On Fri, Oct 11, 2013 at 12:51 PM, Manman Ren <[email protected]>wrote: >> >>> Hi, David >>> >>> I just noticed this has great size reduction on xalan (a SPEC >>> benchmark), thanks for the work. >>> The number of MDNodes in a lto debug build decreased from 29M to 12M. >>> >> >> Great - thanks for the stats. >> >> >>> This may degrade the debugger's speed since we are now emitting >>> declarations instead of definitions, and the debugger will have to search >>> for the definition. >>> >> >> Perhaps. I suppose moreso on Apple platforms where debug info isn't >> linked, so searching multiple object files' debug info could be more >> costly. But do the accelerator tables handle this by making it easy to find >> the object file with the definition? >> >> >>> One example is building XercesWrapperNavigator.cpp with -O0 -g, we are >>> now emitting a forward declaration for XercesDocumentWrapper. >>> XercesWrapperNavigator has a member (m_d) pointing to >>> XercesDocumentWrapper, and we call m_d->func() inside >>> XercesWrapperNavigator.cpp. >>> >> >> Do you have any evidence that this adversely affects debugger performance? >> > For our internal tool chains, we now have to perform a string search to > find the definition. In theory, the extra search should make it slower. > It'd be really nice to quantify this. > Yes, the accelerator table can help the search. > > >> >> >>> 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
