Enumerations

Enumerates the calling conventions supported by LLVM.

See more

public enum CallingConvention

Enumerates the supported kind of clauses.

See more

public enum LandingPadClause : IRValue

Represents unsigned integral types and operations.

public enum Unsigned : IntegralConstantRepresentation

Represents signed integral types and operations.

public enum Signed : IntegralConstantRepresentation

Represents floating types and operations.

public enum Floating : NumericalConstantRepresentation

Represents struct types and operations.

public enum Struct : ConstantRepresentation

Represents vector types and operations.

public enum Vector : ConstantRepresentation

DWARF expressions describe how to compute a value or specify a location. They are expressed in terms of DWARF operations that operate on a stack of values.

A DWARF expression is encoded as a stream of operations, each consisting of an opcode followed by zero or more literal operands.

See more

public enum DWARFExpression

Enumerates the kinds of attributes of LLVM functions and function parameters.

See more

public enum AttributeKind : String

Represents the possible indices of function attributes.

See more

public enum AttributeIndex : ExpressibleByIntegerLiteral, RawRepresentable

Enumerates the supported models of reference of thread-local variables.

These models are listed from the most general, but least optimized, to the fastest, but most restrictive in general, as architectural differences play a role in determining the access patterns for thread-local storage.

In general, support for thread-local storage in statically-linked applications is limited: some platforms may not even define the behavior of TLS in such cases. This is usually not an issue as statically-linked code only ever has one TLS block, the offset of the variables within that block is known, and support for additional dynamic loading of code in statically-linked code is limited.

Computing the thread-specific address of a TLS variable is usually a dynamic process that relies on an ABI-defined function call (usually __tls_get_addr) to do the heavy lifting.

TLS access models fall into two classes: static and dynamic. Regardless of the actual model used, the dynamic linker must process all relocations for thread-local variables whenever the module is loaded. Some models, therefore, provide for a decrease in the overall number of relocations at a cost of restrictions on which modules can access variables.

See more

public enum ThreadLocalModel

Enumerates the kind of metadata nodes.

See more

public enum IRMetadataKind

Enumerates the kinds of values present in LLVM IR.

See more

public enum IRValueKind

JITError represents the different kinds of errors the JIT compiler can throw.

See more

public enum JITError : Error, CustomStringConvertible

Visibility enumerates available visibility styles.

See more

public enum Visibility

Linkage enumerates the supported kinds of linkage for global values. All global variables and functions have a linkage.

See more

public enum Linkage

StorageClass enumerates the storage classes for globals in a Portable Executable file.

See more

public enum StorageClass

Enumerates values representing whether or not this global value’s address is significant in this module or the program at large. A global value’s address is considered significant if it is referenced by any module in the final program.

This attribute is intended to be used only by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. Constant global values with unnamed addresses and identical initializers may be merged by LLVM. Note that a global value with an unnamed address may be merged with a global value with a significant address resulting in a global value with a significant address.

See more

public enum UnnamedAddressKind

Enumerates the possible failures that can be thrown initializing a MemoryBuffer.

See more

public enum MemoryBufferError : Error

Source languages known to DWARF.

See more

public enum DWARFSourceLanguage

Enumerates the supported identifying tags for corresponding DWARF Debugging Information Entries (DIEs) known to LLVM.

See more

public enum DWARFTag : UInt32

Describes how a base type is encoded and to be interpreted by a debugger.

See more

public enum DIAttributeTypeEncoding

The amount of debug information to emit.

See more

public enum DWARFEmissionKind

Represents the possible errors that can be thrown while interacting with a Module object.

See more

public enum ModuleError : Error, CustomStringConvertible

Enumerates the possible failures that can be thrown initializing a MemoryBuffer.

See more

public enum BinaryFileError : Error

Enumerates the opcodes of instructions available in the LLVM IR language.

See more

public enum OpCode : CaseIterable

Species the behavior that should occur on overflow during mathematical operations.

See more

public enum OverflowBehavior

The condition codes available for integer comparison instructions.

See more

public enum IntPredicate

The condition codes available for floating comparison instructions.

See more

public enum RealPredicate

AtomicOrdering enumerates available memory ordering semantics.

Atomic instructions (cmpxchg, atomicrmw, fence, atomic load, and atomic store) take ordering parameters that determine which other atomic instructions on the same address they synchronize with. These semantics are borrowed from Java and C++0x, but are somewhat more colloquial. If these descriptions aren’t precise enough, check those specs (see spec references in the atomics guide). fence instructions treat these orderings somewhat differently since they don’t take an address. See that instruction’s documentation for details.

See more

public enum AtomicOrdering : Comparable

AtomicReadModifyWriteOperation enumerates the kinds of supported atomic read-write-modify operations.

See more

public enum AtomicReadModifyWriteOperation

Enumerates the dialects of inline assembly LLVM’s parsers can handle.

See more

public enum InlineAssemblyDialect

A subset of supported LLVM IR optimizer passes.

See more

public enum Pass

ByteOrder enumerates the ordering semantics of sequences of bytes on a particular target architecture.

See more

public enum ByteOrder

LLVM-provided high-level optimization levels.

Each level has a specific goal and rationale.

See more

public enum CodeGenOptLevel

The relocation model types supported by LLVM.

See more

public enum RelocationModel

The model that generated code should follow. Code Models enables particular styles of generated code that may be more suitable for each enumerated domain. Code Models differ in addressing (absolute versus position independent), code size, data size and address range.

Documentation of these modes paraphrases the Intel System V ABI AMD64 Architecture Processor Supplement.

See more

public enum CodeModel

The supported types of files codegen can produce.

See more

public enum CodegenFileType

Represents one of a few errors that can be thrown by a TargetMachine

See more

public enum TargetMachineError : Error, CustomStringConvertible