[cfe-dev] [LLVMdev] proposal for exploiting undefined behavior much more aggressively

[Chandler Carruth]

On Fri, Jul 27, 2012 at 1:35 AM, <annulen at yandex.ru> wrote:

>
>
> 27.07.12, 03:30, "Chris Lattner" <clattner at apple.com>:
>
> >On Jul 26, 2012, at 9:58 AM, John Regehr wrote:
> >> http://blog.regehr.org/archives/761
> >
> >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.
> >
> >A specific example is code like this (which is quite common):
> >
> >int ftoi(float F) {
> >  return *(int*)&F;
> >}
> >
> >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.
> >
>
> 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.


I think we're approaching this a bit backwards.

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.

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.


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.

[1]: Of course, perhaps Chris is thinking something else. ;] This is just
my two cents.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120727/81dafc2d/attachment.html>