... | ... | @@ -52,20 +52,19 @@ Here's an overview of the module structure of the top levels of GHC library. ( |
|
|
Parse Rename Typecheck Optimise CodeGen
|
|
|
```
|
|
|
|
|
|
# The compilation pipeline
|
|
|
# The driver pipeline
|
|
|
|
|
|
|
|
|
When GHC compiles a module, it calls other programs, and generates a series of intermediate files. Here's a summary of the process.
|
|
|
(source reference: [compiler/main/DriverPipeline.hs](/trac/ghc/browser/ghc/compiler/main/DriverPipeline.hs))
|
|
|
The driver pipeline consist of a couple of phases that call other programs and generate a series of intermediate files. Code responsible for managing the order of phases is in [compiler/main/DriverPhases.hs](/trac/ghc/browser/ghc/compiler/main/DriverPhases.hs), while managing the driver pipeline as a whole is coded in [compiler/main/DriverPipeline.hs](/trac/ghc/browser/ghc/compiler/main/DriverPipeline.hs). Note that driver pipeline is not the same thing as compilation pipeline: the latter is part of the former.
|
|
|
|
|
|
|
|
|
We start with `Foo.hs` or `Foo.lhs`, the "l" specifing whether literate style is being used.
|
|
|
Let's take a look at the overall structure of the driver pipeline. When we compile `Foo.hs` or `Foo.lhs` ("lhs" extension means that Literate Haskell is being used) the following phases are being called (some of them depending on additional conditions like file extensions or enabled flags):
|
|
|
|
|
|
- Run the **unlit pre-processor**, `unlit`, to remove the literate markup, generating `Foo.lpp`. The `unlit` processor is a C program kept in [utils/unlit](/trac/ghc/browser/ghc/utils/unlit).
|
|
|
|
|
|
- Run the **C preprocessor**, `cpp`, (if `-cpp` is specified), generating `Foo.hspp`.
|
|
|
|
|
|
- Run **the compiler itself**. This does not start a separate process; it's just a call to a Haskell function. This step always generates an ['interface file'](commentary/compiler/iface-files)`Foo.hi`, and depending on what flags you give, it also generates a compiled file. As GHC supports three backend code generators currently (a native code generator, a c code generator and an llvm code generator) the possible range of outputs depends on the backend used. All three support assembly output:
|
|
|
- Run **the compiler itself**. This does not start a separate process; it's just a call to a Haskell function. This step always generates an ['interface file'](commentary/compiler/iface-files)`Foo.hi`, and depending on what flags you give, it also generates a compiled file. As GHC supports three backend code generators currently (a native code generator, a C code generator and an llvm code generator) the possible range of outputs depends on the backend used. All three support assembly output:
|
|
|
|
|
|
- Object code: no flags required, file `Foo.o` (supported by all three backends)
|
|
|
- Assembly code: flag `-S`, file `Foo.s` (supported by all three backends)
|
... | ... | |