GHC.Driver.Backend

ghc-9.4.0.20220501: The GHC API

Safe Haskell | Safe-Inferred
Language | Haskell2010

GHC.Driver.Backend

Description

Code generation backends

Synopsis

- data Backend
  - = NCG
  - | LLVM
  - | ViaC
  - | Interpreter
  - | NoBackend
- platformDefaultBackend :: Platform -> Backend
- platformNcgSupported :: Platform -> Bool
- backendProducesObject :: Backend -> Bool
- backendRetainsAllBindings :: Backend -> Bool

# Documentation

data Backend Source #

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

Instances details

Read Backend Source # |
Instance details Defined in GHC.Driver.Backend Methods readsPrec :: Int -> ReadS Backend Source # readList :: ReadS [Backend] Source # readPrec :: ReadPrec Backend Source # readListPrec :: ReadPrec [Backend] Source #
Show Backend Source # |
Instance details Defined in GHC.Driver.Backend Methods showsPrec :: Int -> Backend -> ShowS Source # show :: Backend -> String Source # showList :: [Backend] -> ShowS Source #
Eq Backend Source # |
Instance details Defined in GHC.Driver.Backend Methods (==) :: Backend -> Backend -> Bool # (/=) :: Backend -> Backend -> Bool #
Ord Backend Source # |
Instance details 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 #

platformDefaultBackend :: Platform -> Backend Source #

Default backend to use for the given platform.

platformNcgSupported :: Platform -> Bool Source #

Is the platform supported by the Native Code Generator?

backendProducesObject :: Backend -> Bool Source #

Will this backend produce an object file on the disk?

backendRetainsAllBindings :: Backend -> Bool Source #

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.