ghc-8.6.4: The GHC API

Safe HaskellNone
LanguageHaskell2010

CLabel

Contents

Synopsis

Documentation

data CLabel Source #

CLabel is an abstract type that supports the following operations:

  • Pretty printing
  • In a C file, does it need to be declared before use? (i.e. is it guaranteed to be already in scope in the places we need to refer to it?)
  • If it needs to be declared, what type (code or data) should it be declared to have?
  • Is it visible outside this object file or not?
  • Is it "dynamic" (see details below)
  • Eq and Ord, so that we can make sets of CLabels (currently only used in outputting C as far as I can tell, to avoid generating more than one declaration for any given label).
  • Converting an info table label into an entry label.

CLabel usage is a bit messy in GHC as they are used in a number of different contexts:

  • By the C-- AST to identify labels
  • By the unregisterised C code generator (PprC) for naming functions (hence the name CLabel)
  • By the native and LLVM code generators to identify labels

For extra fun, each of these uses a slightly different subset of constructors (e.g. AsmTempLabel and AsmTempDerivedLabel are used only in the NCG and LLVM backends).

In general, we use IdLabel to represent Haskell things early in the pipeline. However, later optimization passes will often represent blocks they create with LocalBlockLabel where there is no obvious Name to hang off the label.

Instances
Eq CLabel # 
Instance details

Defined in CLabel

Methods

(==) :: CLabel -> CLabel -> Bool #

(/=) :: CLabel -> CLabel -> Bool #

Ord CLabel # 
Instance details

Defined in CLabel

Outputable CLabel # 
Instance details

Defined in CLabel

data ForeignLabelSource Source #

Record where a foreign label is stored.

Constructors

ForeignLabelInPackage UnitId

Label is in a named package

ForeignLabelInExternalPackage

Label is in some external, system package that doesn't also contain compiled Haskell code, and is not associated with any .hi files. We don't have to worry about Haskell code being inlined from external packages. It is safe to treat the RTS package as "external".

ForeignLabelInThisPackage

Label is in the package currenly being compiled. This is only used for creating hacky tmp labels during code generation. Don't use it in any code that might be inlined across a package boundary (ie, core code) else the information will be wrong relative to the destination module.

pprDebugCLabel :: CLabel -> SDoc Source #

For debugging problems with the CLabel representation. We can't make a Show instance for CLabel because lots of its components don't have instances. The regular Outputable instance only shows the label name, and not its other info.

mkAsmTempDieLabel :: CLabel -> CLabel Source #

Construct a label for a DWARF Debug Information Entity (DIE) describing another symbol.

addLabelSize :: CLabel -> Int -> CLabel Source #

Update the label size field in a ForeignLabel

foreignLabelStdcallInfo :: CLabel -> Maybe Int Source #

Get the label size field from a ForeignLabel

isBytesLabel :: CLabel -> Bool Source #

Whether label is a top-level string literal

isForeignLabel :: CLabel -> Bool Source #

Whether label is a non-haskell label (defined in C code)

isSomeRODataLabel :: CLabel -> Bool Source #

Whether label is a .rodata label

isStaticClosureLabel :: CLabel -> Bool Source #

Whether label is a static closure label (can come from haskell or cmm)

Predicates

maybeLocalBlockLabel :: CLabel -> Maybe BlockId Source #

If a label is a local block label then return just its BlockId, otherwise Nothing.

externallyVisibleCLabel :: CLabel -> Bool Source #

Is a CLabel visible outside this object file or not? From the point of view of the code generator, a name is externally visible if it has to be declared as exported in the .o file's symbol table; that is, made non-static.

isMathFun :: CLabel -> Bool Source #

Check whether a label corresponds to a C function that has a prototype in a system header somehere, or is built-in to the C compiler. For these labels we avoid generating our own C prototypes.

labelDynamic :: DynFlags -> Module -> CLabel -> Bool Source #

Does a CLabel need dynamic linkage?

When referring to data in code, we need to know whether that data resides in a DLL or not. [Win32 only.] labelDynamic returns True if the label is located in a DLL, be it a data reference or not.

isLocalCLabel :: Module -> CLabel -> Bool Source #

Is a CLabel defined in the current module being compiled?

Sometimes we can optimise references within a compilation unit in ways that we couldn't for inter-module references. This provides a conservative estimate of whether a CLabel lives in the current module.

Conversions