<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Oct 11, 2013 at 2:41 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">>>> Do you have any evidence that this adversely affects debugger<br>
>>> performance?<br>
>><br>
>> For our internal tool chains, we now have to perform a string search to<br>
>> find the definition. In theory, the extra search should make it slower.<br>
><br>
><br>
> It'd be really nice to quantify this.<br>
><br>
>><br>
>> Yes, the accelerator table can help the search.<br>
>><br>
<br>
</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></blockquote><div><br></div><div>I don't have numbers right now, in theory extra search means slower response (maybe insignificant).<br></div><div><br></div><div>I was asking whether it is worthwhile to guard this change with a flag. If -no-limit-debug-info is not the right flag,</div>
<div>is it reasonable to have a different flag for this? Does gcc has a flag to turn this off?</div><div><br></div><div>Manman</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<span class="HOEnZb"><font color="#888888"><br>
-eric<br>
</font></span><div class="im HOEnZb"><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 effects of<br>
>>>> this patch?<br>
>>><br>
>>><br>
>>> GCC does this by default, at least on Linux - I haven't tested on 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 large<br>
>>> regression in debug info size (it's worth about ~20% on Clang/LLVM 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 high<br>
> confidence as the vtable based debug info emission mechanism, I'm not sure<br>
> we want to group these together. (eg: it seems likely that a user might have<br>
> issues with the minimization caused by -flimit-debug-info and want to 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>
</div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> cfe-commits mailing list<br>
> <a href="mailto:cfe-commits@cs.uiuc.edu">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>
</div></div></blockquote></div><br></div></div>