
Taming Undefined Behavior in LLVM - ingve
https://blog.regehr.org/archives/1496
======
jstarks
The post mentions:

> Finally, we noticed that there has been an interesting bit of convergent
> evolution in compiler IRs: basically all heavily optimizing AOT compilers
> (including GCC, MSVC, and Intel CC) have their own versions of deferred UB.

Does anyone know how GCC's deferred UB solution works and whether it suffers
from the same problems as LLVM's?

~~~
jstarks
Answering my own question, the paper [1] referenced by the post goes into some
detail on this in section 9.

[1] [http://www.cs.utah.edu/~regehr/papers/undef-
pldi17.pdf](http://www.cs.utah.edu/~regehr/papers/undef-pldi17.pdf)

------
nickpsecurity
The thing that trips me out is I kept seeing opposite claims in R&D: undefined
behavior can improve performance a lot; using type-directed compilation can
improve performance a lot. Most compilers rely on undefined behavior for
aggressive optimizations. I wonder what the cutting-edge is on opposite end
for type-safe languages and type-directed optimizations. FLINT for SML is the
first one I saw like that:

[http://flint.cs.yale.edu/flint/publications/tcps.html](http://flint.cs.yale.edu/flint/publications/tcps.html)

~~~
erlehmann_
To me, undefined behaviour analysis and typing analysis seem very similar:
Both allow a compiler to infer things that can help improve performance … So
why do you see the claims that both can help performance as “opposite”?

~~~
saurik
The type system proves things about my program that must be true and disallows
invalid programs. The undefined behavior system decides things about my
program that may or may not be true and just breaks my program when one of us
is wrong (and I don't even care who: whether it is the compiler that came up
with something insane or me trying to do the impossible <\- I honestly don't
care).

~~~
erlehmann_
I think when undefined behaviour is used for optimizations the programmer does
not want it is more of a misunderstanding than one party (programmer or
compiler) necessarily being “wrong”, as a compiler assumes that a program
should make sense (i.e. is not undefined) and infers things from that. To
clarify, would you say that assumption is problematic?

------
magnumkarter
Does anyone know of any other good blogs about LLVM and compilers?

~~~
dataking
[http://blog.llvm.org/](http://blog.llvm.org/)

------
pizlonator
I'm still waiting on an A:B test that shows that UB in the compiler makes my
computer run faster.

~~~
benchaney
What?

~~~
marvy
I think what pizlonator meant is that some languages like C have pervasive
undefined behavior. (For instance, INT_MAX + 1 is allowed to erase your hard
drive.) The claim is that this allows compiler optimizations that would
otherwise not be possible. The question is: how bad would that be? Let's turn
off all these optimizations and see how much the benchmark scores drop. If
everything is twice as slow, then maybe this undefined stuff is worth it. If
everything is one percent slower, then maybe it's not.

~~~
DrJokepu
I think the performance implications of bounds checking are fairly well
studied.

~~~
nickpsecurity
That part of the field is still in exploration phase. The reason is that you
can mix run-time checks with no checks for performance enhancement. Static
analysis and other schemes are used to prove specific code doesn't need
checks. The rest get checks automatically. Performance varies per scheme
applied with overhead going down significantly over past decade. We don't yet
know the answer on just how much spatial or temporal safety we can get at what
cost.

