Version 23 (modified by dias, 6 years ago) (diff)


An Integrated Code Generator for GHC

We propose reworking GHC's back end into an Integrated Code Generator, which will widen the interface between machine-independent and machine-dependent parts of the back end. We wish to dissolve the barrier between the current machine-independent transformations (CPS conversion, stack layout, etc) and the native-code generators (instruction selection, calling conventions, register allocation -- including spilling to the C stack, etc). The goal is instead to have a code generator that integrates both machine-independent and machine-dependent components, which will interact through wide but well-specified interfaces. From this refactoring we expect the following benefits:

  • The back end will be simpler overall, primarily because the refactoring will reduce or eliminate duplication of code
  • Complexity will be isolated in two modules with well-defined interfaces: a dataflow engine and a register allocator
  • GHC will generate better machine code, primarily because important decisions about register usage will be made at a later stage of translation and will exploit knowledge of the actual target machine.

Design elements

The important elements of our design are as follows:

  1. Build two big hammers, and hit as many nails as possible. (The big hammers are the dataflow optimization engine and a coalescing register allocator.) The hammer itself may be big and complicated, but using a big hammer should be easy and should give easily predictable results.
  2. Load all back ends into every instance of the compiler, and treat every compilation as a cross-compilation. Despite having been used in production compilers for at least twenty years, this technique is still seen as somewhat unorthodox, but it removes many #ifdefs and saves significant complexity at compiler-configuration time. Removing #ifdefs also mitigates problems with validating the compiler under different build configurations.

Design philosophy

State-of-the art dataflow optimization and register allocation both require complex implementations. We live with this complexity because creating new clients is easy.


Proposed compilation pipeline

  1. Convert from STG to an control flow graph CmmGraph:
  2. Instruction selection:
  3. Optimise:
  4. Proc-point analysis, and transformation
  5. Register allocation
  6. Stack layout
  7. Tidy up

Convert from STG to control flow graph

Convert from STG to an control flow graph CmmGraph (compiler/cmm/ZipCfg.hs, compiler/cmm/ZipCfgCmmRep.hs). This step is Simon PJ's "new code generator" from September 2007. This conversion may introduce new variables, stack slots, and compile-time constants.

STG -> CmmGraph Cmm.Middle Cmm.Last
  • How do we refer to locations on the stack when we haven't laid it out yet? The compiler names a stack slot using the idea of a "late compile-time constant," which is just a symbolic constant that will be replaced with an actual stack offset when the stack layout is chosen.One departure from the old code generator is that we do not build a Cmm abstract-syntax tree; instead we go straight to a control-flow graph.

In practice, we first generate an "abstract control flow graph", CmmAGraph, which makes the business of generating fresh BlockIds more convenient, and convert that to a CmmGraph. The former is convenient for construction but cannot be analysed; the latter is concrete, and can be analyzed, transformed, and optimized.

Instruction selection

Instruction selection: each Cmm Middle and Last node in the control-flow graph is replaced with a new graph in which the nodes are machine instructions.

CmmGraph Cmm.Middle Cmm.Last -> CmmGraph I386.Middle I386.Last

The I386.Middle type represents computational machine instructions; the I386.Last type represents control-transfer instructions. The choice of representation is up to the author of the back end, but for continuity with the existing native code generators, we expect to begin by using algebraic data types inspired by the existing definitions in compiler/nativeGen/MachInstrs.hs.

Note that the graph still contains:

  • Variables (ie local register that are not yet mapped to particular machine registers)
  • Stack-slot addressing modes, which include late-bound compile-time constants, such as the offset in the frame of the a variable spill location, or BlockId? stack-top-on-entry.

The invariant is that each node could be done by one machine instruction, provided each LocalReg maps to a (suitable) physical register; and an instruction involving a stack-slot can cope with (Sp+n).

An extremely important distinction from the existing code is that we plan to eliminate #ifdef and instead provide multiple datatypes, e.g., in I386.hs, PpcInstrs.hs, Sparc.hs, and so on.

Similarly, we expect a an instruction selector for each back end, so for example, we might have a transformation that maps LGraph Cmm.Middle Cmm.Last (with variables, stack slots, and compile-time constants) -> LGraph I86.Middle I386.Last (with variables, stack slots, and compile-time constants).

We expect to abstract away from the details of these representations by borrowing some abstractions from Machine SUIF. In the longer term we would like to support RTL-based representations such as are used in gcc, vpo and Quick C--. What this means is that I386.Middle (etc) is an abstract type, an instance of type class that supports the functions that the rest of the pipeline needs. For example:

class Instr i where
  defs :: i -> [LocalReg]
  uses :: i -> [LocalReg]

This allows us to make code improvements machine-independent, by using machine-dependent functions to capture the semantics of instructions. Figuring out precisely what the interface should be is a key step. For example, to support copy propagation we might want an operation

  isCopy :: i -> Maybe (LocalReg,LocalReg)

Similarly, to support peephole optimsation (eg transform x = y+2; p = bits32[x] to p = bits32[y+2]) we might want something like


The substExprs operation returns a Just iff a substitution took place.

Interfaces like these would require the machine-specific abstract type i to contain enough information to reconstruct a LocalReg or CmmExpr. Later one, we'll need to construct SRTs too, so we must continue to track pointer-hood.


   rtl :: i -> RTL

which is particularly cheap for architectures that do use RTL as the representation type.


Optimise the code. LGraph Instrs (with variables, stack slots, and compile-time constants) -> LGraph Instrs (with variables, stack slots, and compile-time constants), such as

  • Branch chain elimination.
  • Remove unreachable blocks (dead code).
  • Constant propagation.
  • Copy propagation.
  • Lazy code motion (hoisting, sinking, partial redundancy elimination).

Proc-point analysis



  • Proc points are found, and the appropriate control-transfer instructions are inserted.
  • Why so early(before register allocation, stack layout)? Depending on the back end (think of C as the worst case), the proc-point analysis might have to satisfy some horrible calling convention. We want to make these requirements explicit before we get to the register allocator. We also want to exploit the register allocator to make the best possible decisions about which live variables (if any) should be in registers at a proc point.

Register allocation


That is, register allocation takes LGraph Instrs (with variables, stack slots) -> LGraph Instrs (with stack slots only). No more variables!


Stack layout

Stack Layout: LGraph Instrs (with stack slots, and compile-time constants) -> LGraph Instrs

  • Choose a stack layout.
  • Replace references to stack slots with addresses on the stack.
  • Replace compile-time constants with offsets into the stack.

No more stack-slot references.

Tidy up

  1. Proc-point splitting: LGraph Instrs -> [LGraph Instrs]
    • Each proc point gets its own procedure.
  2. Code layout: LGraph Instrs -> [String]
    • A reverse postorder depth-first traversal simultaneously converts the graph to sequential code and converts each instruction into an assembly-code string: Assembly code ahoy!



  3. Most of the optimizer need not know the representation of machine instructions.
  5. RTLs are not a new representation; they are a trivial extension of existing Cmm representations.