A Context represents execution states for the core LLVM IR system.

See more

public class Context

A Module represents the top-level structure of an LLVM program. An LLVM module is effectively a translation unit or a collection of translation units merged together.

See more

public final class Module : CustomStringConvertible

Represents a sequence of metadata entries attached to a global value that are uniqued by kind.

See more

public class AttachedMetadata

A Comdat object represents a particular COMDAT section in a final generated ELF or COFF object file. All COMDAT sections are keyed by a unique name that the linker uses, in conjunction with the section’s selectionKind to determine how to treat conflicting or identical COMDAT sections at link time.

COMDAT sections are typically used by languages where multiple translation units may define the same symbol, but where One-Definition-Rule (ODR)-like concepts apply (perhaps because taking the address of the object referenced by the symbol is defined behavior). For example, a C++ header file may define an inline function that cannot be successfully inlined at all call sites. The C++ compiler would then emit a COMDAT section in each object file for the function with the .any selection kind and the linker would pick any section it desires before emitting the final object file.

It is important to be aware of the selection kind of a COMDAT section as these provide strengths and weaknesses at compile-time and link-time. It is also important to be aware that only certain platforms support mixing identically-keyed COMDAT sections with mixed selection kinds e.g. COFF supports mixing .any and .largest, WebAssembly only supports .any, and Mach-O doesn’t support COMDAT sections at all.

When targeting COFF, there are also restrictions on the way global objects must appear in COMDAT sections. All global objects and aliases to those global objects must belong to a COMDAT group with the same name and must have greater than local linkage. Else the local symbol may be renamed in the event of a collision, defeating code-size savings.

The combined use of COMDATS and sections may yield surprising results. For example:

let module = Module(name: "COMDATTest")
let builder = IRBuilder(module: module)

let foo = module.comdat(named: "foo")
let bar = module.comdat(named: "bar")

var g1 = builder.addGlobal("g1", initializer: IntType.int8.constant(42))
g1.comdat = foo
var g2 = builder.addGlobal("g2", initializer: IntType.int8.constant(42))
g2.comdat = bar

From the object file perspective, this requires the creation of two sections with the same name. This is necessary because both globals belong to different COMDAT groups and COMDATs, at the object file level, are represented by sections.

See more

public class Comdat

A DIBuilder is a helper object used to generate debugging information in the form of LLVM metadata. A DIBuilder is usually paired with an IRBuilder to allow for the generation of code and metadata in lock step.

See more

public final class DIBuilder

A Function represents a named function body in LLVM IR source. Functions in LLVM IR encapsulate a list of parameters and a sequence of basic blocks and provide a way to append to that sequence to build out its body.

See more

public class Function : IRGlobal

A Global represents a region of memory allocated at compile time instead of at runtime. A global variable must either have an initializer, or make reference to an external definition that has an initializer.

See more

public final class Global : IRGlobal

An IRBuilder is a helper object that generates LLVM instructions. IR Builders keep track of a position within a function or basic block and has methods to insert instructions at that position.

See more

public class IRBuilder

An Intrinsic represents an intrinsic known to LLVM.

Intrinsic functions have well known names and semantics and are required to follow certain restrictions. Overall, these intrinsics represent an extension mechanism for the LLVM language that does not require changing all of the transformations in LLVM when adding to the language (or the bitcode reader/writer, the parser, etc…).

Intrinsic function names must all start with an llvm. prefix. This prefix is reserved in LLVM for intrinsic names; thus, function names may not begin with this prefix. Intrinsic functions must always be external functions: you cannot define the body of intrinsic functions. Intrinsic functions may only be used in call or invoke instructions: it is illegal to take the address of an intrinsic function.

Some intrinsic functions can be overloaded, i.e., the intrinsic represents a family of functions that perform the same operation but on different data types. Because LLVM can represent over 8 million different integer types, overloading is used commonly to allow an intrinsic function to operate on any integer type. One or more of the argument types or the result type can be overloaded to accept any integer type. Argument types may also be defined as exactly matching a previous argument’s type or the result type. This allows an intrinsic function which accepts multiple arguments, but needs all of them to be of the same type, to only be overloaded with respect to a single argument or the result.

Overloaded intrinsics will have the names of its overloaded argument types encoded into its function name, each preceded by a period. Only those types which are overloaded result in a name suffix. Arguments whose type is matched against another type do not. For example, the llvm.ctpop function can take an integer of any width and returns an integer of exactly the same integer width. This leads to a family of functions such as i8 @llvm.ctpop.i8(i8 %val) and i29 @llvm.ctpop.i29(i29 %val). Only one type, the return type, is overloaded, and only one type suffix is required. Because the argument’s type is matched against the return type, it does not require its own name suffix.

Dynamic Member Lookup For Intrinsics

This library provides a dynamic member lookup facility for retrieving intrinsic selectors. For any LLVM intrinsic selector of the form llvm.foo.bar.baz, the name of the corresponding dynamic member is that name with any dots replaced by underscores.

For example:

llvm.foo.bar.baz -> Intrinsic.ID.llvm_foo_bar_baz
llvm.stacksave -> Intrinsic.ID.llvm_stacksave
llvm.x86.xsave64 -> Intrinsic.ID.llvm_x86_xsave64

Any existing underscores do not need to be replaced, e.g. llvm.va_copy becomes Intrinsic.ID.llvm_va_copy.

For overloaded intrinsics, the non-overloaded prefix excluding the explicit type parameters is used and normalized according to the convention above.

For example:

llvm.sinf64 -> Intrinsic.ID.llvm_sin
llvm.memcpy.p0i8.p0i8.i32 -> Intrinsic.ID.llvm_memcpy
llvm.bswap.v4i32 -> Intrinsic.ID.llvm_bswap

See more

public class Intrinsic : Function

A JIT is a Just-In-Time compiler that will compile and execute LLVM IR that has been generated in a Module. It can execute arbitrary functions and return the value the function generated, allowing you to write interactive programs that will run as soon as they are compiled.

The JIT is fundamentally lazy, and allows control over when and how symbols are resolved.

See more

public final class JIT

MemoryBuffer provides simple read-only access to a block of memory, and provides simple methods for reading files and standard input into a memory buffer. In addition to basic access to the characters in the file, this interface guarantees you can read one character past the end of the file, and that this character will read as ‘\0’.

The ‘\0’ guarantee is needed to support an optimization – it’s intended to be more efficient for clients which are reading all the data to stop reading when they encounter a ‘\0’ than to continually check the file position to see if it has reached the end of the file.

See more

public class MemoryBuffer : Sequence

A NamedMetadata object represents a module-level metadata value identified by a user-provided name. Named metadata is generated lazily when operands are attached.

See more

public class NamedMetadata

An in-memory representation of a format-independent object file.

See more

public class ObjectFile

A sequence for iterating over the sections in an object file.

See more

public class SectionSequence : Sequence

A sequence for iterating over the relocations in an object file.

See more

public class RelocationSequence : Sequence

A sequence for iterating over the symbols in an object file.

See more

public class SymbolSequence : Sequence

A FunctionPassManager is an object that collects a sequence of passes which run over a particular IR construct, and runs each of them in sequence over each such construct.

See more

public class FunctionPassManager

A TargetData encapsulates information about the data requirements of a particular target architecture and can be used to retrieve information about sizes and offsets of types with respect to this target.

See more

public class TargetData

A Target object represents an object that encapsulates information about a host architecture, vendor, ABI, etc.

See more

public class Target

A TargetMachine object represents an object that encapsulates information about a particular machine (i.e. CPU type) associated with a target environment.

See more

public class TargetMachine