<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Oct 11, 2013 at 3:49 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div>On Fri, Oct 11, 2013 at 3:46 PM, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>>> The accelerator table should help - since it only has definitions and<br>
>> it's on by default for darwin. What's up that's causing a performance<br>
>> degradation?<br>
><br>
><br>
> I don't have numbers right now, in theory extra search means slower response<br>
> (maybe insignificant).<br>
><br>
<br>
</div>Probably insignificant here given the debugger is using the<br>
accelerator tables. I'd need to know what other use you're thinking<br>
about to determine whether or not the slowdown could be damaging<br>
otherwise. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><br>
> I was asking whether it is worthwhile to guard this change with a flag. If<br>
> -no-limit-debug-info is not the right flag,<br>
> is it reasonable to have a different flag for this? Does gcc has a flag to<br>
> turn this off?<br>
><br>
<br>
</div>Nope.<br></blockquote><div><br></div></div><div>I believe it does, actually:<br><br><dt style="font-size:medium;font-family:'Times New Roman'"><code>-femit-class-debug-always</code></dt><dd style="font-size:medium;font-family:'Times New Roman'">
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. <br>
<br></dd></div><div> </div><div>It's not a precise description of the feature, but it certainly seems to correlate with the behavior. </div><div><br></div><div><br></div><div><div>struct foo {</div><div> virtual ~foo();</div>
<div>};</div><div><br></div><div>int main() {</div><div> foo f;</div><div>}</div></div><div><br></div><div>Without the flag, a declaration of 'foo' is emitted, with the flag a definition of 'foo' is emitted (by GCC ToT).</div>
</div></div></div></blockquote><div><br></div><div>Thanks for the information!</div><div><br></div><div>I think it is reasonable to add a similar flag for clang:</div><div>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.</div>
<div>2> The possibility that the actual use where we would emit the class def could get stripped</div><div><br></div><div>What do you think?</div><div><br></div><div>Manman </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span><font color="#888888"><br>
-eric<br>
</font></span><div><div><br>
<br>
> Manman<br>
><br>
>><br>
>> -eric<br>
>><br>
>> >>><br>
>> >>><br>
>> >>>><br>
>> >>>> Is it reasonable for this commit to be enabled only for<br>
>> >>>> limit-debug-info, when no-limit-debug-info is on, we don't see<br>
>> >>>> effects of<br>
>> >>>> this patch?<br>
>> >>><br>
>> >>><br>
>> >>> GCC does this by default, at least on Linux - I haven't tested on<br>
>> >>> MacOS.<br>
>> >>> I would guess it does so there too (but as you point out, there are<br>
>> >>> different tradeoffs there, so I might be wrong).<br>
>> >>><br>
>> >>> I'd like to understand the performance tradeoff to justify such a<br>
>> >>> large<br>
>> >>> regression in debug info size (it's worth about ~20% on Clang/LLVM<br>
>> >>> based on<br>
>> >>> my experiments).<br>
>> >><br>
>> >><br>
>> >> Our default is -limit-debug-info, so this will be on by default. I was<br>
>> >> asking whether we should guard this so when people use<br>
>> >> "-fno-limit-debug-info", they will get the definition.<br>
>> ><br>
>> ><br>
>> > -flimit-debug-info has some relatively rough heuristics that aren't as<br>
>> > high<br>
>> > confidence as the vtable based debug info emission mechanism, I'm not<br>
>> > sure<br>
>> > we want to group these together. (eg: it seems likely that a user might<br>
>> > have<br>
>> > issues with the minimization caused by -flimit-debug-info and want to<br>
>> > turn<br>
>> > it off, if in doing so they also turn off the vtable based,<br>
>> > higher-confidence optimization, that would be unfortunate)<br>
>> ><br>
>> > - David<br>
>> ><br>
>> >><br>
>> >><br>
>> >> Thanks,<br>
>> >> Manman<br>
>> >><br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>> - David<br>
>> >>><br>
>> >>>><br>
>> >>>><br>
>> >>>> Thanks,<br>
>> >>>> Manman<br>
>> >>>><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > cfe-commits mailing list<br>
>> > <a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a><br>
>> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div>