Hacker News Reader

Comment by nickpsecurity | Hacker News Reader

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

View on HN

They're not at all opposite: one can think of reasoning about types as reasoning about UB. For instance, if a value is of type `int`, it's undefined behaviour for it to be of type `float`, and so the compiler can optimise based on this fact (there's just the added bonus that the compiler also checks this UB "perfectly": code won't violate the rules).

Essentially, undefined behaviour exposed to the user is an extra layer of "types"/rules on top of the underlying type system, both of which the compiler can use for optimisation purposes (but only one of which the compiler checks for the programmer). More and more advanced type systems can push more of the former into the latter (e.g. for index-out-of-bounds, in the limit, dependent typing can allow one to statically ensure that all integers are in range of the arrays they index).

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”?

One claims to be undefined. One claims to use typed things to produce other typed things. I could see them doing similar or dissimilar things. Undefined vs specific types just seemed opposite to me.

The thing about undefined behavior is that it means the compiler can do whatever it wants. Most of the time, since the compiler wants to create efficient code, it can just assume that invalid values won't occur the same way a type system can allow a compiler to know that invalid values can't occur.

EDIT: More information here http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

Appreciate the link.

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).

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?

Most of the complaints about UB-based optimization that I've seen are from when the compiler uses UB to assume some type restraint that the programmer wishes it did not. E.g.:

  int v = *p;
  if (p == NULL) { /* ... */ }

The compiler uses UB to annotate the type information on p to indicate it's non-null, and then performs type-directed optimization.

> then performs type-directed optimization.

which can mean erasure of the if block, to be perfectly clear here.

edit: any good compiler will warn about the assignment or throw an error, though, using the right compiler options.

Reply on news.ycombinator.com