-
-
- Primitive Types - -
- High Level Structure + +
- Constants + + +
- Other Values +
- Instruction Reference
- Terminator Instructions +
- Binary Operations
-
-
- 'add' Instruction -
- 'sub' Instruction -
- 'mul' Instruction -
- 'div' Instruction -
- 'rem' Instruction -
- 'setcc' Instructions +
- 'add' Instruction +
- 'sub' Instruction +
- 'mul' Instruction +
- 'udiv' Instruction +
- 'sdiv' Instruction +
- 'fdiv' Instruction +
- 'urem' Instruction +
- 'srem' Instruction +
- 'frem' Instruction
- Bitwise Binary Operations + +
- Vector Operations + + +
- Memory Access and Addressing Operations + -
- Memory Access Operations + +
- Conversion Operations
-
-
- 'malloc' Instruction -
- 'free' Instruction -
- 'alloca' Instruction -
- 'load' Instruction -
- 'store' Instruction -
- 'getelementptr' Instruction +
- 'trunc .. to' Instruction +
- 'zext .. to' Instruction +
- 'sext .. to' Instruction +
- 'fptrunc .. to' Instruction +
- 'fpext .. to' Instruction +
- 'fptoui .. to' Instruction +
- 'fptosi .. to' Instruction +
- 'uitofp .. to' Instruction +
- 'sitofp .. to' Instruction +
- 'ptrtoint .. to' Instruction +
- 'inttoptr .. to' Instruction +
- 'bitcast .. to' Instruction
- Other Operations +
- Intrinsic Functions
-
-
-
- Variable Argument Handling Intrinsics
-
-
- 'llvm.va_start' Intrinsic -
- 'llvm.va_end' Intrinsic -
- 'llvm.va_copy' Intrinsic +
- Variable Argument Handling Intrinsics + + +
- Accurate Garbage Collection Intrinsics + + +
- Code Generator Intrinsics + + +
- Standard C Library Intrinsics + + +
- Bit Manipulation Intrinsics + + +
- Debugger intrinsics +
- Exception Handling intrinsics
Written by Chris Lattner and Vikram Adve
- - +
- Variable Argument Handling Intrinsics
| -Abstract - |
-
+
-
- This document is a reference manual for the LLVM assembly language. LLVM is - an SSA based representation that provides type safety, low level operations, - flexibility, and the capability of representing 'all' high level languages - cleanly. It is the common code representation used throughout all phases of - the LLVM compilation strategy. -- - - +
This document is a reference manual for the LLVM assembly language. +LLVM is an SSA based representation that provides type safety, +low-level operations, flexibility, and the capability of representing +'all' high-level languages cleanly. It is the common code +representation used throughout all phases of the LLVM compilation +strategy.
+| -Introduction - |
-
+
-The LLVM code representation is designed to be used in three different forms: as
-an in-memory compiler IR, as an on-disk bytecode representation, suitable for
-fast loading by a dynamic compiler, and as a human readable assembly language
-representation. This allows LLVM to provide a powerful intermediate
-representation for efficient compiler transformations and analysis, while
-providing a natural means to debug and visualize the transformations. The three
-different forms of LLVM are all equivalent. This document describes the human
-readable representation and notation.
- -The LLVM representation aims to be a light weight and low level while being -expressive, typed, and extensible at the same time. It aims to be a "universal -IR" of sorts, by being at a low enough level that high level ideas may be -cleanly mapped to it (similar to how microprocessors are "universal IR's", -allowing many source languages to be mapped to them). By providing type -information, LLVM can be used as the target of optimizations: for example, -through pointer analysis, it can be proven that a C automatic variable is never -accessed outside of the current function... allowing it to be promoted to a -simple SSA value instead of a memory location.
+
The LLVM code representation is designed to be used in three +different forms: as an in-memory compiler IR, as an on-disk bytecode +representation (suitable for fast loading by a Just-In-Time compiler), +and as a human readable assembly language representation. This allows +LLVM to provide a powerful intermediate representation for efficient +compiler transformations and analysis, while providing a natural means +to debug and visualize the transformations. The three different forms +of LLVM are all equivalent. This document describes the human readable +representation and notation.
+ +The LLVM representation aims to be light-weight and low-level +while being expressive, typed, and extensible at the same time. It +aims to be a "universal IR" of sorts, by being at a low enough level +that high-level ideas may be cleanly mapped to it (similar to how +microprocessors are "universal IR's", allowing many source languages to +be mapped to them). By providing type information, LLVM can be used as +the target of optimizations: for example, through pointer analysis, it +can be proven that a C automatic variable is never accessed outside of +the current function... allowing it to be promoted to a simple SSA +value instead of a memory location.
+ +
Well Formedness
-
+
-It is important to note that this document describes 'well formed' LLVM assembly
-language. There is a difference between what the parser accepts and what is
-considered 'well formed'. For example, the following instruction is
-syntactically okay, but not well formed:
+
It is important to note that this document describes 'well formed' +LLVM assembly language. There is a difference between what the parser +accepts and what is considered 'well formed'. For example, the +following instruction is syntactically okay, but not well formed:
- %x = add int 1, %x + %x = add i32 1, %x-...because the definition of %x does not dominate all of its uses. The -LLVM infrastructure provides a verification pass that may be used to verify that -an LLVM module is well formed. This pass is automatically run by the parser -after parsing input assembly, and by the optimizer before it outputs bytecode. -The violations pointed out by the verifier pass indicate bugs in transformation -passes or input to the parser.
- - +
...because the definition of %x does not dominate all of +its uses. The LLVM infrastructure provides a verification pass that may +be used to verify that an LLVM module is well formed. This pass is +automatically run by the parser after parsing input assembly and by +the optimizer before it outputs bytecode. The violations pointed out +by the verifier pass indicate bugs in transformation passes or input to +the parser.
+| -Identifiers - |
-
+
-LLVM uses three different forms of identifiers, for different purposes:
- Numeric constants are represented as you would expect: 12, -3 123.421, etc. Floating point constants have an optional hexidecimal notation. -
- Named values are represented as a string of characters with a '%' prefix. For example, %foo, %DivisionByZero, %a.really.long.identifier. The actual regular expression used is '%[a-zA-Z$._][a-zA-Z$._0-9]*'. -
- Unnamed values are represented as an unsigned numeric value with a '%' prefix. For example, %12, %2, %44. -
- Named values are represented as a string of characters with a '%' prefix. + For example, %foo, %DivisionByZero, %a.really.long.identifier. The actual + regular expression used is '%[a-zA-Z$._][a-zA-Z$._0-9]*'. + Identifiers which require other characters in their names can be surrounded + with quotes. In this way, anything except a " character can be used + in a name. + +
- Unnamed values are represented as an unsigned numeric value with a '%' + prefix. For example, %12, %2, %44. + +
- Constants, which are described in a section about + constants, below. + -LLVM requires the values start with a '%' sign for two reasons: Compilers don't -need to worry about name clashes with reserved words, and the set of reserved -words may be expanded in the future without penalty. Additionally, unnamed -identifiers allow a compiler to quickly come up with a temporary variable -without having to avoid symbol table conflicts.
- Comments are delimited with a ';' and go until the end of line. -
- Unnamed temporaries are created when the result of a computation is not - assigned to a named value. -
- Unnamed temporaries are numbered sequentially -
- Comments are delimited with a ';' and go until the end of + line. + +
- Unnamed temporaries are created when the result of a computation is not + assigned to a named value. + +
- Unnamed temporaries are numbered sequentially + + + +
+
LLVM uses three different forms of identifiers, for different +purposes:
-
-
+
+
LLVM requires that values start with a '%' sign for two reasons: Compilers +don't need to worry about name clashes with reserved words, and the set of +reserved words may be expanded in the future without penalty. Additionally, +unnamed identifiers allow a compiler to quickly come up with a temporary +variable without having to avoid symbol table conflicts.
-Reserved words in LLVM are very similar to reserved words in other languages. -There are keywords for different opcodes ('add', -'cast', 'ret', -etc...), for primitive type names ('void', -'uint', etc...), and others. These reserved -words cannot conflict with variable names, because none of them start with a '%' -character.+
Reserved words in LLVM are very similar to reserved words in other +languages. There are keywords for different opcodes +('add', + 'bitcast', + 'ret', etc...), for primitive type names ('void', 'i32', etc...), +and others. These reserved words cannot conflict with variable names, because +none of them start with a '%' character.
-Here is an example of LLVM code to multiply the integer variable '%X' -by 8:+
Here is an example of LLVM code to multiply the integer variable +'%X' by 8:
+ +The easy way:
-The easy way:- %result = mul uint %X, 8 + %result = mul i32 %X, 8-After strength reduction: +
After strength reduction:
+- %result = shl uint %X, ubyte 3 + %result = shl i32 %X, i8 3-And the hard way: +
And the hard way:
+- add uint %X, %X ; yields {uint}:%0 - add uint %0, %0 ; yields {uint}:%1 - %result = add uint %1, %1 + add i32 %X, %X ; yields {i32}:%0 + add i32 %0, %0 ; yields {i32}:%1 + %result = add i32 %1, %1-This last way of multiplying %X by 8 illustrates several important lexical features of LLVM:
+
This last way of multiplying %X by 8 illustrates several +important lexical features of LLVM:
-
-
-...and it also show a convention that we follow in this document. When +
...and it also shows a convention that we follow in this document. When demonstrating instructions, we will follow an instruction with a comment that defines the type and name of value produced. Comments are shown in italic -text.
- -The one non-intuitive notation for constants is the optional hexidecimal form of -floating point constants. For example, the form 'double -0x432ff973cafa8000' is equivalent to (but harder to read than) 'double -4.5e+15' which is also supported by the parser. The only time hexadecimal -floating point constants are useful (and the only time that they are generated -by the disassembler) is when an FP constant has to be emitted that is not -representable as a decimal floating point number exactly. For example, NaN's, -infinities, and other special cases are represented in their IEEE hexadecimal -format so that assembly and disassembly do not cause any bits to change in the -constants.
+text.
+| -Type System - |
-
+
-The LLVM type system is one of the most important features of the intermediate
-representation. Being typed enables a number of optimizations to be performed
-on the IR directly, without having to do extra analyses on the side before the
-transformation. A strong type system makes it easier to read the generated code
-and enables novel analyses and transformations that are not feasible to perform
-on normal three address code representations.
+ +
+ +LLVM programs are composed of "Module"s, each of which is a +translation unit of the input programs. Each module consists of +functions, global variables, and symbol table entries. Modules may be +combined together with the LLVM linker, which merges function (and +global variable) definitions, resolves forward declarations, and merges +symbol table entries. Here is an example of the "hello world" module:
+ +; Declare the string constant as a global constant... +%.LC0 = internal constant [13 x i8 ] c"hello world\0A\00" ; [13 x i8 ]* - +; External declaration of the puts function +declare i32 %puts(i8 *) ; i32(i8 *)* +; Global variable / Function body section separator +implementation +; Definition of main function +define i32 %main() { ; i32()* + ; Convert [13x i8 ]* to i8 *... + %cast210 = getelementptr [13 x i8 ]* %.LC0, i64 0, i64 0 ; i8 * + + ; Call puts function to write out the string to stdout... + call i32 %puts(i8 * %cast210) ; i32 + ret i32 0+ +
}
This example is made up of a global variable +named ".LC0", an external declaration of the "puts" +function, and a function definition +for "main".
+ +In general, a module is made up of a list of global values, +where both functions and global variables are global values. Global values are +represented by a pointer to a memory location (in this case, a pointer to an +array of char, and a pointer to a function), and have one of the following linkage types.
+ +Due to a limitation in the current LLVM assembly parser (it is limited by +one-token lookahead), modules are split into two pieces by the "implementation" +keyword. Global variable prototypes and definitions must occur before the +keyword, and function definitions must occur after it. Function prototypes may +occur either before or after it. In the future, the implementation keyword may +become a noop, if the parser gets smarter.
+ +| -Primitive Types - |
-
-
-The primitive types are the fundemental building blocks of the LLVM system. The
-current set of primitive types are as follows:
- internal + +
- Global values with internal linkage are only directly accessible by + objects in the current module. In particular, linking code into a module with + an internal global value may cause the internal to be renamed as necessary to + avoid collisions. Because the symbol is internal to the module, all + references can be updated. This corresponds to the notion of the + 'static' keyword in C. + + +
- linkonce: + +
- Globals with "linkonce" linkage are merged with other globals of + the same name when linkage occurs. This is typically used to implement + inline functions, templates, or other code which must be generated in each + translation unit that uses it. Unreferenced linkonce globals are + allowed to be discarded. + + +
- weak: + +
- "weak" linkage is exactly the same as linkonce linkage, + except that unreferenced weak globals may not be discarded. This is + used for globals that may be emitted in multiple translation units, but that + are not guaranteed to be emitted into every translation unit that uses them. + One example of this are common globals in C, such as "int X;" at + global scope. + + +
- appending: + +
- "appending" linkage may only be applied to global variables of + pointer to array type. When two global variables with appending linkage are + linked together, the two global arrays are appended together. This is the + LLVM, typesafe, equivalent of having the system linker append together + "sections" with identical names when .o files are linked. + + +
- extern_weak: +
- The semantics of this linkage follow the ELF model: the symbol is weak + until linked, if not linked, the symbol becomes null instead of being an + undefined reference. + +
- externally visible: + +
- If none of the above identifiers are used, the global is externally + visible, meaning that it participates in linkage and can be used to resolve + external symbol references. + + +
- dllimport: + +
- "dllimport" linkage causes the compiler to reference a function
+ or variable via a global pointer to a pointer that is set up by the DLL
+ exporting the symbol. On Microsoft Windows targets, the pointer name is
+ formed by combining
_imp__and the function or variable name. +
+
+ - dllexport: + +
- "dllexport" linkage causes the compiler to provide a global
+ pointer to a pointer in a DLL, so that it can be referenced with the
+ dllimport attribute. On Microsoft Windows targets, the pointer
+ name is formed by combining
_imp__and the function or variable + name. +
+
+ - "ccc" - The C calling convention: + +
- This calling convention (the default if no other calling convention is + specified) matches the target C calling conventions. This calling convention + supports varargs function calls and tolerates some mismatch in the declared + prototype and implemented declaration of the function (as does normal C). + + +
- "fastcc" - The fast calling convention: + +
- This calling convention attempts to make calls as fast as possible + (e.g. by passing things in registers). This calling convention allows the + target to use whatever tricks it wants to produce fast code for the target, + without having to conform to an externally specified ABI. Implementations of + this convention should allow arbitrary tail call optimization to be supported. + This calling convention does not support varargs and requires the prototype of + all callees to exactly match the prototype of the function definition. + + +
- "coldcc" - The cold calling convention: + +
- This calling convention attempts to make code in the caller as efficient + as possible under the assumption that the call is not commonly executed. As + such, these calls often preserve all registers so that the call does not break + any live ranges in the caller side. This calling convention does not support + varargs and requires the prototype of all callees to exactly match the + prototype of the function definition. + + +
- "cc <n>" - Numbered convention: + +
- Any calling convention may be specified by number, allowing + target-specific calling conventions to be used. Target specific calling + conventions start at 64. + +
- "default" - Default style: -
- On ELF, default visibility means that the declaration is visible to other + modules and, in shared libraries, means that the declared entity may be + overridden. On Darwin, default visibility means that the declaration is + visible to other modules. Default visibility corresponds to "external + linkage" in the language. + +
- "hidden" - Hidden style: +
- Two declarations of an object with hidden visibility refer to the same + object if they are in the same shared object. Usually, hidden visibility + indicates that the symbol will not be placed into the dynamic symbol table, + so no other module (executable or shared library) can reference it + directly. + +
- -
-
-
+ Linkage Types
+
- |
+
-
-
+All Global Variables and Functions have one of the following types of linkage: + + +
+ The next two types of linkage are targeted for Microsoft Windows platform + only. They are designed to support importing (exporting) symbols from (to) + DLLs. + + +
For example, since the ".LC0" +variable is defined to be internal, if another module defined a ".LC0" +variable and was linked with this one, one of the two would be renamed, +preventing a collision. Since "main" and "puts" are +external (i.e., lacking any linkage declarations), they are accessible +outside of the current module. +It is illegal for a function declaration +to have any linkage type other than "externally visible", dllimport, +or extern_weak. + + |
+ +
+ +LLVM functions, calls +and invokes can all have an optional calling convention +specified for the call. The calling convention of any pair of dynamic +caller/callee must match, or the behavior of the program is undefined. The +following calling conventions are supported by LLVM, and more may be added in +the future:
+ +-
+
More calling conventions can be added/defined on an as-needed basis, to +support pascal conventions or any other well-known target-independent +convention.
+ +
Type Classifications
-
+
+All Global Variables and Functions have one of the following visibility styles: +
-These different primitive types fall into a few useful classifications:+
-
+
| signed | sbyte, short, int, long, float, double |
| unsigned | ubyte, ushort, uint, ulong |
| integer | ubyte, sbyte, ushort, short, uint, int, ulong, long |
| integral | bool, ubyte, sbyte, ushort, short, uint, int, ulong, long |
| floating point | float, double |
| first class | bool, ubyte, sbyte, ushort, short, uint, int, ulong, long, float, double, pointer |
+
| -Derived Types - |
-
+
Global variables define regions of memory allocated at compilation time +instead of run-time. Global variables may optionally be initialized, may have +an explicit section to be placed in, and may +have an optional explicit alignment specified. A +variable may be defined as a global "constant," which indicates that the +contents of the variable will never be modified (enabling better +optimization, allowing the global data to be placed in the read-only section of +an executable, etc). Note that variables that need runtime initialization +cannot be marked "constant" as there is a store to the variable.
-The real power in LLVM comes from the derived types in the system. This is what -allows a programmer to represent arrays, functions, pointers, and other useful -types. Note that these derived types may be recursive: For example, it is -possible to have a two dimensional array.+
+LLVM explicitly allows declarations of global variables to be marked +constant, even if the final definition of the global is not. This capability +can be used to enable slightly better optimization of the program, but requires +the language definition to guarantee that optimizations based on the +'constantness' are valid for the translation units that do not include the +definition. +
+ +As SSA values, global variables define pointer values that are in +scope (i.e. they dominate) all basic blocks in the program. Global +variables always define a pointer to their "content" type because they +describe a region of memory, and all memory objects in LLVM are +accessed through pointers.
+ +LLVM allows an explicit section to be specified for globals. If the target +supports it, it will emit globals to the section specified.
+ +An explicit alignment may be specified for a global. If not present, or if +the alignment is set to zero, the alignment of the global is set by the target +to whatever it feels convenient. If an explicit alignment is specified, the +global is forced to have at least that much alignment. All alignments must be +a power of 2.
+ +For example, the following defines a global with an initializer, section, + and alignment:
++ %G = constant float 1.0, section "foo", align 4 ++
Array Type
-
-
- zext +
- This indicates that the parameter should be zero extended just before + a call to this function. +
- sext +
- This indicates that the parameter should be sign extended just before + a call to this function. +
- inreg +
- This indicates that the parameter should be placed in register (if + possible) during assembling function call. Support for this attribute is + target-specific +
- sret +
- This indicates that the parameter specifies the address of a structure + that is the return value of the function in the source program. +
- noreturn +
- This function attribute indicates that the function never returns. This + indicates to LLVM that every call to this function should be treated as if + an unreachable instruction immediately followed the call. +
- nounwind +
- This function attribute indicates that the function type does not use + the unwind instruction and does not allow stack unwinding to propagate + through it. +
- E +
- Specifies that the target lays out data in big-endian form. That is, the + bits with the most significance have the lowest address location. +
- e +
- Specifies that hte target lays out data in little-endian form. That is, + the bits with the least significance have the lowest address location. +
- p:size:abi:pref +
- This specifies the size of a pointer and its abi and + preferred alignments. All sizes are in bits. Specifying the pref + alignment is optional. If omitted, the preceding : should be omitted + too. +
- isize:abi:pref +
- This specifies the alignment for an integer type of a given bit + size. The value of size must be in the range [1,2^23). +
- vsize:abi:pref +
- This specifies the alignment for a vector type of a given bit + size. +
- fsize:abi:pref +
- This specifies the alignment for a floating point type of a given bit + size. The value of size must be either 32 (float) or 64 + (double). +
- asize:abi:pref +
- This specifies the alignment for an aggregate type of a given bit + size. +
- E - big endian +
- p:32:64:64 - 32-bit pointers with 64-bit alignment +
- i1:8:8 - i1 is 8-bit (byte) aligned +
- i8:8:8 - i8 is 8-bit (byte) aligned +
- i16:16:16 - i16 is 16-bit aligned +
- i32:32:32 - i32 is 32-bit aligned +
- i64:32:64 - i64 has abi alignment of 32-bits but preferred + alignment of 64-bits +
- f32:32:32 - float is 32-bit aligned +
- f64:64:64 - double is 64-bit aligned +
- v64:64:64 - 64-bit vector is 64-bit aligned +
- v128:128:128 - 128-bit vector is 128-bit aligned +
- a0:0:1 - aggregates are 8-bit aligned
- If the type sought is an exact match for one of the specifications, that + specification is used. +
- If no match is found, and the type sought is an integer type, then the + smallest integer type that is larger than the bitwidth of the sought type is + used. If none of the specifications are larger than the bitwidth then the the + largest integer type is used. For example, given the default specifications + above, the i7 type will use the alignment of i8 (next largest) while both + i65 and i256 will use the alignment of i64 (largest specified). +
- If no match is found, and the type sought is a vector type, then the + largest vector type that is smaller than the sought vector type will be used + as a fall back. This happens because <128 x double> can be implemented in + terms of 64 <2 x double>, for example. +
Overview:
+ +LLVM function definitions consist of the "define" keyord, +an optional linkage type, an optional +visibility style, an optional +calling convention, a return type, an optional +parameter attribute for the return type, a function +name, a (possibly empty) argument list (each with optional +parameter attributes), an optional section, an +optional alignment, an opening curly brace, a list of basic blocks, and a +closing curly brace. + +LLVM function declarations consist of the "declare" keyword, an +optional linkage type, an optional +visibility style, an optional +calling convention, a return type, an optional +parameter attribute for the return type, a function +name, a possibly empty list of arguments, and an optional alignment.
+ +A function definition contains a list of basic blocks, forming the CFG for +the function. Each basic block may optionally start with a label (giving the +basic block a symbol table entry), contains a list of instructions, and ends +with a terminator instruction (such as a branch or +function return).
+ +The first basic block in a program is special in two ways: it is immediately +executed on entrance to the function, and it is not allowed to have predecessor +basic blocks (i.e. there can not be any branches to the entry block of a +function). Because the block can have no predecessors, it also cannot have any +PHI nodes.
-The array type is a very simple derived type that arranges elements sequentially -in memory. The array type requires a size (number of elements) and an -underlying data type.+
LLVM functions are identified by their name and type signature. Hence, two +functions with the same name but different parameter lists or return values are +considered different functions, and LLVM will resolve references to each +appropriately.
-Syntax:
-- [<# elements> x <elementtype>] -+
LLVM allows an explicit section to be specified for functions. If the target +supports it, it will emit functions to the section specified.
-The number of elements is a constant integer value, elementtype may be any type -with a size.+
An explicit alignment may be specified for a function. If not present, or if +the alignment is set to zero, the alignment of the function is set by the target +to whatever it feels convenient. If an explicit alignment is specified, the +function is forced to have at least that much alignment. All alignments must be +a power of 2.
-Examples:
+The return type and each parameter of a function type may have a set of + parameter attributes associated with them. Parameter attributes are + used to communicate additional information about the result or parameters of + a function. Parameter attributes are considered to be part of the function + type so two functions types that differ only by the parameter attributes + are different function types.
+ +Parameter attributes are simple keywords that follow the type specified. If + multiple parameter attributes are needed, they are space separated. For + example:
+ %someFunc = i16 (i8 sext %someParam) zext + %someFunc = i16 (i8 zext %someParam) zext+
Note that the two function types above are unique because the parameter has + a different attribute (sext in the first one, zext in the second). Also note + that the attribute for the function result (zext) comes immediately after the + argument list.
+ +Currently, only the following parameter attributes are defined:
+-
+
+Modules may contain "module-level inline asm" blocks, which corresponds to the +GCC "file scope inline asm" blocks. These blocks are internally concatenated by +LLVM and treated as a single unit, but may be separated in the .ll file if +desired. The syntax is very simple: +
+ ++ module asm "inline asm code goes here" + module asm "more can go here" +
The strings can contain any character by escaping non-printable characters. + The escape sequence used is simply "\xx" where "xx" is the two digit hex code + for the number. +
+ ++ The inline asm code is simply printed to the machine code .s file when + assembly code is generated. +
+A module may specify a target specific data layout string that specifies how
+data is to be laid out in memory. The syntax for the data layout is simply:
+
target datalayout = "layout specification" ++The layout specification consists of a list of specifications separated +by the minus sign character ('-'). Each specification starts with a letter +and may include other information after the letter to define some aspect of the +data layout. The specifications accepted are as follows: +
-
+
When constructing the data layout for a given target, LLVM starts with a +default set of specifications which are then (possibly) overriden by the +specifications in the datalayout keyword. The default specifications +are given in this list:
-
- [40 x int ]: Array of 40 integer values.
- [41 x int ]: Array of 41 integer values.
- [40 x uint]: Array of 40 unsigned integer values.
+
When llvm is determining the alignment for a given type, it uses the +following rules: +
-
+
-
-
-
