GHC.Driver.Backend

Code generation backends

Documentation

data Backend

Code generation backends.

GHC supports several code generation backends serving different purposes (producing machine code, producing ByteCode for the interpreter) and supporting different platforms.

Constructors

NCG

Native code generator backend.

Compiles Cmm code into textual assembler, then relies on an external assembler toolchain to produce machine code.

Only supports a few platforms (X86, PowerPC, SPARC).

See GHC.CmmToAsm.

LLVM

LLVM backend.

Compiles Cmm code into LLVM textual IR, then relies on LLVM toolchain to produce machine code.

It relies on LLVM support for the calling convention used by the NCG backend to produce code objects ABI compatible with it (see "cc 10" or "ghccc" calling convention in https://llvm.org/docs/LangRef.html#calling-conventions).

Support a few platforms (X86, AArch64, s390x, ARM).

See GHC.CmmToLlvm

ViaC

Via-C backend.

Compiles Cmm code into C code, then relies on a C compiler to produce machine code.

It produces code objects that are *not* ABI compatible with those produced by NCG and LLVM backends.

Produced code is expected to be less efficient than the one produced by NCG and LLVM backends because STG registers are not pinned into real registers. On the other hand, it supports more target platforms (those having a valid C toolchain).

See GHC.CmmToC

Interpreter

ByteCode interpreter.

Produce ByteCode objects (BCO, see GHC.ByteCode) that can be interpreted. It is used by GHCi.

Currently some extensions are not supported (foreign primops).

See GHC.StgToByteCode

NoBackend

No code generated.

Use this to disable code generation. It is particularly useful when GHC is used as a library for other purpose than generating code (e.g. to generate documentation with Haddock) or when the user requested it (via -fno-code) for some reason.

Instances

Eq Backend

Defined in GHC.Driver.Backend

Methods

(==) :: Backend -> Backend -> Bool

(/=) :: Backend -> Backend -> Bool

Ord Backend

Defined in GHC.Driver.Backend

Methods

compare :: Backend -> Backend -> Ordering

(<) :: Backend -> Backend -> Bool

(<=) :: Backend -> Backend -> Bool

(>) :: Backend -> Backend -> Bool

(>=) :: Backend -> Backend -> Bool

max :: Backend -> Backend -> Backend

min :: Backend -> Backend -> Backend

Read Backend

Defined in GHC.Driver.Backend

Methods

readsPrec :: Int -> ReadS Backend

readList :: ReadS [Backend]

readPrec :: ReadPrec Backend

readListPrec :: ReadPrec [Backend]

Show Backend

Defined in GHC.Driver.Backend

Methods

showsPrec :: Int -> Backend -> ShowS

show :: Backend -> String

showList :: [Backend] -> ShowS

platformDefaultBackend :: Platform -> Backend

Default backend to use for the given platform.

platformNcgSupported :: Platform -> Bool

Is the platform supported by the Native Code Generator?

backendProducesObject :: Backend -> Bool

Will this backend produce an object file on the disk?

backendRetainsAllBindings :: Backend -> Bool

Does this backend retain *all* top-level bindings for a module, rather than just the exported bindings, in the TypeEnv and compiled code (if any)?

Interpreter backend does this, so that GHCi can call functions inside a module.

When no backend is used we also do it, so that Haddock can get access to the GlobalRdrEnv for a module after typechecking it.