On Fri, Jul 27, 2012 at 1:35 AM,  <span dir="ltr"><<a href="mailto:annulen@yandex.ru" target="_blank" class="cremed">annulen@yandex.ru</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
27.07.12, 03:30, "Chris Lattner" <<a href="mailto:clattner@apple.com" class="cremed">clattner@apple.com</a>>:<br>
<div class="im"><br>
>On Jul 26, 2012, at 9:58 AM, John Regehr wrote:<br>
>> <a href="http://blog.regehr.org/archives/761" target="_blank" class="cremed">http://blog.regehr.org/archives/761</a><br>
><br>
</div>>Its an interesting post, but Id like to point out that it is a non-goal for the project to be actively hostile to users of the compiler.  :)  It is useful to have debugging tools for people who really care, but 'exploiting' undefined behavior just for the sake of breaking code is a non-goal.<br>

<div class="im">><br>
>A specific example is code like this (which is quite common):<br>
><br>
>int ftoi(float F) {<br>
>  return *(int*)&F;<br>
>}<br>
><br>
>This is a violation of the C spec, due to type-based aliasing issues (the right approach is to use a union).  That said, we go out of our way to not break this sort of idiom, because it is obvious to the compiler and actively hostile to a widely used pattern in dusty deck code.<br>

><br>
<br>
</div>This behavior could be made optional, e.g. if someone has checked the code and found it UB-free he could allow aggressive UB exploiting.</blockquote><div><br></div><div>I think we're approaching this a bit backwards.</div>
<div><br></div><div>We should first see if there is some non-trivial performance gain to be had by leveraging the undefined behavior. If so, we should then evaluate whether it is reasonable to hope for real world programmers to avoid such undefined behavior, and whether the code we have today is reasonably free of it.</div>
<div><br></div><div>If all three of these hold true (the first is actually the one i find least likely to be true in many cases), only then should we implement an optimization which leverages the UB, and we should first make some attempt to implement reasonable warnings and runtime checking of the UB to help users who run afoul of the optimization.</div>
<div><br></div><div><br></div><div>I think[1] that the primary issue is that it should never be the *goal* to exploit undefined behavior. The goal should be faster generated code, smaller generated code, or some other valuable thing for a compiler. Then, if the undefined behavior gives a particular opportunity to reach that goal, we should consider taking that opportunity. To simply willfully transform code with undefined behavior code into ludicrous constructs is to put the cart before the horse.</div>
<div><br></div><div>[1]: Of course, perhaps Chris is thinking something else. ;] This is just my two cents.</div><div><br></div><div>-Chandler</div></div></div>