<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 15, 2013 at 10:13 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank" class="cremed">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 class="adM"><div class="im"><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>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></div><div><div class="adM"><br></div>
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.</div>
</blockquote></div><br></div><div class="gmail_extra">Manman, I really don't like the direction this is going.</div><div class="gmail_extra"><br></div><div class="gmail_extra">There are essentially three ways this should proceed:</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">1) You have a real problem with this behavior, and can provide a clear, and easily understood explanation for what behavior you need. Without this, it doesn't make sense for the open source project to try to fuzzily match some unstated set of expectations for the debug info produced.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">2) You don't have a real problem, but are worried somewhere someone may run into this issue. While this level of concern is admirable, I think the only way we can proceed is to assume that in the absence of concrete user reports of a problem, the problem doesn't exist. Otherwise, even if a problem does manifest, it will be different from our assumptions and we will have planned poorly.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">3) You have a real problem with this behavior, but cannot (for many legitimate reasons perhaps) discuss exactly what the situation is or why that problem exists, or what precise behavior is needed. In this case, I think the only reasonable approach is for you to maintain an internal patch where all the maintainers of that patch at least have the context to understand why it exists and what it is trying to accomplish.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Does that make sense? Let's not go down the path of more flags and more varied behavior unless we have #1.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">-Chandler</div></div>