<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 23, 2013 at 10:44 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.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 dir="ltr"><div class="im">On Wed, Jan 23, 2013 at 10:27 AM, Daniel Dunbar <span dir="ltr"><<a href="mailto:daniel@zuster.org" target="_blank">daniel@zuster.org</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><div class="im">
<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 dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">
<div>On Tue, Jan 22, 2013 at 5:55 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.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 dir="ltr"><div>On Tue, Jan 22, 2013 at 5:42 PM, Argyrios Kyrtzidis <span dir="ltr"><<a href="mailto:kyrtzidis@apple.com" target="_blank">kyrtzidis@apple.com</a>></span> wrote:<br>


</div><div class="gmail_extra"><div class="gmail_quote"><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"><div style="word-wrap:break-word"><div><div><div>On Jan 22, 2013, at 5:23 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>> wrote:</div>



<br><blockquote type="cite"><div dir="ltr">On Tue, Jan 22, 2013 at 4:15 PM, Daniel Dunbar <span dir="ltr"><<a href="mailto:daniel@zuster.org" target="_blank">daniel@zuster.org</a>></span> wrote:<br><div class="gmail_extra">



<div class="gmail_quote">
<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 dir="ltr">Hi Richard,<div><br></div><div>I object pretty strongly to using unreachable here for C++ code bases.</div>




</div></blockquote><div><br></div><div>There was some discussion surrounding this, and I'm still pretty strongly in favor of it...</div></div></div></div></blockquote><div><br></div></div><div>IMHO you still haven't given enough justification; your proposed optimization opportunity in <a href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-October/025326.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-October/025326.html</a> is specific to a full covered switch, which can be handled with an optimization that targets this case.</div>



</div></div></blockquote><div><br></div></div><div>It is applicable to any circumstance where there is a programmer-known invariant that all paths terminate in a return which is not statically determinable. I've seen both predicated code with if/else chains of this form, and switches.</div>


</div></div></div></blockquote><div><br></div></div><div>The right way to handle this is with appropriate annotations. This is simply not a good argument for emitting unreachable.</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">


<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>But I actually think we're approaching this from the wrong direction. The C++ standard is extremely clear that this is UB. Given that, I think we should aggressively tell users about this problem with their code. If the optimization benefits aren't worthwhile, then I would argue for emitting llvm.trap in *all* cases rather than just in non-optimized builds. While I think the optimization benefits are both easy to get and worth it, I don't have a collection of benchmarks that rely on it so I'm not going to fight tooth and nail for it. I just don't understand sacrificing it when we don't have to.</div>


</div></div></div></blockquote><div><br></div></div><div>I'd much prefer llvm.trap in all cases instead of unreachable, although I still don't see much value in forcing users to fix code that from their perspective "works".</div>

</div></div></div></blockquote><div><br></div></div><div>The fundamental question is: do you want to try to define as a language extension the behavior here?</div></div></div></div></blockquote><div><br></div><div style>
No, but just because we choose not to use unreachable doesn't mean we are defining it as a language extension, it just means its  an implementation choice.</div><div style> </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">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> If so, we have a process for that, but I think it will be a painful and fruitless one as I think this language behavior was very well considered by the C++ committee. I do not think this behavior was chosen in ignorance but in a desire that the language work in a certain way.</div>
</div></div></div></blockquote><div><br></div><div style>I don't understand why you are pursuing this rabbit hole, just because the language defines something as undefined doesn't mean the compiler should implement it that way (and obviously we don't do this).</div>
<div style><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"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div>If we don't want to define the behavior here, we do a disservice to the users and to our selves to allow it to persist in the code. </div></div></div></div></blockquote><div><br></div><div style>
I don't agree with this statement. It is in our interest to provide good tools to help users find UB. We do that. It is not necessarily in our interest to *force* users to find all cases of UB.</div><div style><br></div>
<div style>That may well be in your interest for your use case at Google, but that is a policy decision you can enforce in other ways (ubsan, warning policy, etc).</div><div style><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">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Eventually it *will* be exploited to the users detriment and we should tell the user about it quickly and effectively. This is the argument for using llvm.trap. This is the argument I feel *very* strongly about.</div>

<div><br></div><div>The argument to switch from llvm.trap to unreachable in an optimized build is simply one of principles: the user told us to optimize, and the language gave us an opportunity. There isn't some practical, useful behavior being blocked here. We should optimize these cases just as we optimize signed integer overflow even if in the particular situation it didn't help the performance or code size signficantly.</div>

<div><br></div><div><br></div><div>If you want to think about the extent to which this matters, consider inlining. Once inlined, the undefined nature of this pattern is more likely to result in an active bug, and thus the user will more greatly appreciate the trap diagnosing it for them. Also, once inlined the unreachable has much more power and can result in significant simplifications.</div>

<div><br></div><div>To sum up:</div><div>- if we aren't going to define the behavior, we should trap. This will make both programs and future optimizations much more predictable.</div></div></div></div></blockquote><div>
<br></div><div style>I don't agree with this, as before.</div><div style><br></div><div style>You are failing to give good arguments for why this behavior benefits our users. From my perspective, the important question here is "what value is there to the user of emitting unreachable". I haven't heard a good argument for this.</div>
<div><br></div><div>Note that from a user's perspective, just "helping" them find undefined behavior is not value. We have lots of good tools for helping them do that (static analyzer, compiler warnings, ubsan), and so users who want to do that can do so. But there are many code bases and users for whom that is not a priority, and forcing them to do so is actively hurting them. That is an okay tradeoff if there are strong benefits in other ways (strict-aliasing), but if there are not it is just causing them to do "unnecessary" work.</div>
<div style><br></div><div style> - Daniel</div><div style><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">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>
- if we are going to trap, then when optimizing we should leverage that in the hope of secondary and tertiary simplifications</div></div></div></div>
</blockquote></div><br></div><div class="gmail_extra"><br></div></div>