Category: Compilers

  • Learning When Values are Changed by Implicit Integer Casts

    C and C++ perform implicit casts when, for example, you pass an integer-typed variable to a function that expects a different type. When the target type is wider, there’s no problem, but when the target type is narrower or when it is the same size and the other signedness, integer values may silently change when […]

  • What’s the difference between an integer and a pointer?

    (This piece is an alternate introduction and advertisement for a soon-to-be-published research paper.) In an assembly language we typically don’t have to worry very much about the distinction between pointers and integers. Some instructions happen to generate addresses whereas others behave arithmetically, but underneath there’s a single data type: bitvectors. At the opposite end of […]

  • Future Directions for Optimizing Compilers

    I wanted to write a manifesto-ish sort of piece about what compilers are supposed to look like in the future. Nuno was the obvious coauthor since I’ve talked to him about this topic so much that I’m overall not really sure which parts started out as his ideas and which were mine. The article didn’t […]

  • How LLVM Optimizes a Function

    An optimizing, ahead-of-time compiler is usually structured as: A frontend that converts source code into an intermediate representation (IR). A target-independent optimization pipeline: a sequence of passes that successively rewrite the IR to eliminate inefficiencies and forms that cannot be readily translated into machine code. Sometimes called the “middle end.” A target-dependent backend that generates […]

  • How Clang Compiles a Function

    I’ve been planning on writing a post about how LLVM optimizes a function, but it seems necessary to first write about how Clang translates C or C++ into LLVM. This is going to be fairly high-level: rather than looking at Clang’s internals, I’m going to focus on how Clang’s output relates to its input we’re […]

  • Some Goals for High-impact Verified Compiler Research

    I believe that translation validation, a branch of formal methods, is just about ready for widespread use. Translation validation means proving that a particular execution of a compiler did the right thing, as opposed to proving once and for all that every execution of a compiler will do the right thing. These are very different. […]

  • Undefined Behavior in 2017

    This post is jointly authored by Pascal Cuoq and John Regehr. Recently we’ve heard a few people imply that problems stemming from undefined behaviors (UB) in C and C++ are largely solved due to ubiquitous availability of dynamic checking tools such as ASan, UBSan, MSan, and TSan. We are here to state the obvious — […]

  • Pointer Overflow Checking is in LLVM

    Production-grade memory safety for legacy C and C++ code has proven to be a frustratingly elusive goal: plenty of research solutions exist but none of them appear to be deployable as-is. So instead, we have a patchwork of partial solutions such as CFI, ASLR, stack canaries, hardened allocators, and NX. Today’s quick post is about […]

  • Compiler Optimizations are Awesome

    This piece, which I hadn’t gotten around to writing until now since I thought it was all pretty obvious, explains why Daniel J. Bernstein’s talk, The death of optimizing compilers (audio) is wrong, and in fact compiler optimizations are extremely wonderful and aren’t going anywhere. First, the thesis of the talk is that almost all […]

  • Translation Validation of Bounded Exhaustive Test Cases

    This piece is jointly authored by Nuno Lopes and John Regehr. Compilers should be correct, but it is not straightforward to formally verify a production-quality compiler implementation. It is just too difficult to recover the high-level algorithms by looking at an enormous mess of arithmetic, loops, and memory side effects. One solution is to write […]