<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Oct 15, 2013 at 10:09 AM, Manman Ren <span dir="ltr"><<a href="mailto:manman.ren@gmail.com" target="_blank">manman.ren@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><div class="h5">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></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></div></div></blockquote><div><br>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.<br>
<br>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.<br>
<br>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.<br>
<br>- David </div></div></div></div>