Compiler Verification

(Thanks to Pierce, "Software Foundations.")

Common notions

Optional outcomes

Identifiers

A few specific identifiers for use in examples.

States

A randomly chosen example state: X = 100 Y = 20 Z = 2

Source language: arithmetic expressions.

Semantics of the source language, given in a "denotational" style.

N.B. If our source language allowed non-terminating computations or was non-deterministic, we'd probably need to give a relational description instead, e.g. in the following big-step style:

It is easy to show that these are equivalent...

...so for convenience we'll continue to use the functional version. An example program

We can evaluate the denotation of a program directly inside Coq.

The target language: stack machine instructions

HP Calculators, programming languages like Forth and Postscript, and abstract machines like the Java Virtual Machine all evaluate arithmetic expressions using a stack. For instance, the expression

   (2*3)+(3*(4-2))

would be entered as

   2 3 * 3 4 2 - * +

and evaluated like this:

  []            |    2 3 * 3 4 2 - * +
  [2]           |    3 * 3 4 2 - * +
  [3; 2]        |    * 3 4 2 - * +
  [6]           |    3 4 2 - * +
  [3; 6]        |    4 2 - * +
  [4; 3; 6]     |    2 - * +
  [2; 4; 3; 6]  |    - * +
  [2; 3; 6]     |    * +
  [6; 6]        |    +
  [12]          |

We show how to write a small compiler that translates aexps into stack machine instructions. The instruction set for our stack language will consist of the following instructions:

• SPush n: Push the number n on the stack.
• SLoad x: Load the identifier x from the store and push it on the stack
• SPlus: Pop the two top numbers from the stack, add them, and push the result onto the stack.
• SMinus: Similar, but subtract.
• SMult: Similar, but multiply.

Semantics of the target machine

(Again, we could alternatively give this semantics as a step relation.)

Compilers and Correctness

Now we are in a position to define what a compiler is and what it means for a compiler to be correct. A compiler is just a function from source code to target code, allowing for the possibility of failure.

If the compiler succeeds, then the observed behavior of target should match that of source. In this case, all we can "observe" is the overall value of the expression and the final result left on the machine stack.

A simple initial compiler

Again, we can evaluate the result of compilation directly inside Coq.

Coq also supports "extraction" of functions and datatypes to a more efficiently executable language such as OCaml.

(see compver_extract.ml) So properties we prove about s_compile apply directly to the "real" compiler generated by extraction (assuming we trust the extraction process, of course).

Proof of Correctness.

We can give a simple direct proof of compiler correctness. The proof is by induction on the form of aexp being compiled. The only trick is that we must generalize the induction hypothesis to consider arbitrary stacks and code sequences.

A self-checking compiler.

This compiler performs translation validation on its output to check if it is correct. Checking is conservative: it might say "no" even if the output is correct. This particular checker will work by decompiling the output to an aexp and comparing that to the original input. The decompiler, in turn, works by symbolic execution of the program.

We would like to verify that s_compile_check is ok, in other words that our checker is sound. First we show that symbolic execution agrees with real execution.

Now we can show that our checking compiler is correct.

Adding Optimization

So far our two proof approaches get equivalent results, except that the checking compiler might fail-stop. The proof effort is also roughly the same, although the translation validation approach is a bit more complicated because we have to define the checking machinery. In other cases, however, proving correctness of a checker might be substantially easier than a direct proof. Now let's introduce a simple optimization into the compiler. We'll write this as an initial source-to-source transformation on input terms. This transformation simply replaces any expression of the form 0+e with e.

Now here is a compiler incorporating this optimization. Think of this as a very simple multi-stage compiler: source -> optimized source -> target

To do a direct proof of correctness for the optimizing compiler, we can examine the behavior of the optimization and prove that it preserves behavior.

Based on this knowledge, we can reprove correctness of the whole compiler chain.

We can build a checking compiler just as before.

And the same proof shows that this compiler is correct by our definition.

But this compiler fails if the optimizer kicks in, because the decompiled code is not exactly identical to what we started with.

The problem is that we have been very simplistic in writing our checking function. It is obviously not reasonable to expect that the result of decompilation will be syntactically identical to the program we started with. There are two general ways to address this problem. (1) If we assume that we can see (at least part of) the internals of the compiler, we can use knowledge about how the compiler works to predict how the decompiled output will differ from the original, and adjust the comparison accordingly. In the current simple situation, it suffices to run the optimize_0plus function over the original program before doing the comparison. (2) If we assume that the compiler is a black box, we can still attempt to normalize the original program and the decompiled one before comparing. In the current situation, this might mean normalizing arithmetic expressions into sorted polynomials. Obviously, this is a lot more work, but it has the advantage of being insensitive to the precise behavior of the compiler. Note that this normalization approach can be applied to program representations other than the source language. For example, source and target might both be translated into a third language before being compared.