r188739 - Revert "Revert "Revert "Revert "DebugInfo: Omit debug info for dynamic classes in TUs that do not have the vtable for that class""""

[Manman Ren]

On Fri, Oct 11, 2013 at 2:41 PM, Eric Christopher <echristo at gmail.com>wrote:

> >>> 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.
> >>
>
> 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).

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?

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
> > cfe-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131011/7f5e2640/attachment.html>