Written by Chris Lattner and Vikram Adve
+ +
- This document describes the LLVM assembly language. LLVM is an SSA based - representation that is a useful midlevel IR, providing type safety, low level - operations, flexibility, and the capability of representing 'all' high level - languages cleanly. + 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.@@ -117,14 +118,14 @@ 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, type safe, 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 -safety, 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.
+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.
%x = add int 1, %x
-...because only a phi node may refer to itself.
-The LLVM api provides a verification pass (created by the
-createVerifierPass function) that may be used to verify that an LLVM
-module is well formed. This pass is automatically run by the parser after
+...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.
-Describe the typesetting conventions here.
+
@@ -193,8 +193,8 @@ After strength reduction:
And the hard way:
The LLVM type system is one of the most important features of the intermediate
-representation. Being strongly 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.
+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.
-The written form for the type system was heavily influenced by the syntactic
-problems with types in the C language1.
+
@@ -288,7 +288,8 @@ These different primitive types fall into a few useful classifications:
Well Formedness
@@ -138,15 +139,14 @@ syntactically okay, but not well formed:
- add uint %X, %X ; yields {int}:%0
- add uint %0, %0 ; yields {int}:%1
+ add uint %X, %X ; yields {uint}:%0
+ add uint %0, %0 ; yields {uint}:%1
%result = add uint %1, %1
@@ -232,15 +232,15 @@ constants.
| signed | sbyte, short, int, long, float, double |
| unsigned | ubyte, ushort, uint, ulong |
| integral | ubyte, sbyte, ushort, short, uint, int, ulong, long |
| 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 |
@@ -392,8 +393,9 @@ LLVM.
+memory. The packing of the field types is defined to match the ABI of the +underlying processor. The elements of a structure may be any type that has a +size.
Structures are accessed using 'load and 'store' by getting a pointer to a field with the 'getelementptr' instruction.
+(which corresponds to the static keyword in C, when used at global scope).
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 (lacking "internal" declarations), -they are accessible outside of the current module. It is illegal for a function -declaration to be "internal".
+and "puts" are external (i.e., lacking "internal" +declarations), they are accessible outside of the current module. It is illegal +for a function declaration to be "internal".
@@ -522,15 +524,15 @@ declaration to be "internal".
-As SSA values, global variables define pointer values that are in scope in -(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.
+As SSA values, global variables define pointer values that are in scope +(i.e. they dominate) for 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.
@@ -565,10 +567,9 @@ function).
The LLVM instruction set consists of several different classifications of -instructions: terminator instructions, a unary instruction, binary -instructions, memory instructions, and other instructions.
+instructions: terminator instructions, binary instructions, memory +instructions, and other instructions.
@@ -578,11 +579,11 @@ href="#otherops">other instructions.
+program ends with a "Terminator" instruction, which indicates which block should +be executed after the current block is finished. These terminator instructions +typically yield a 'void' value: they produce control flow, not values +(the one exception being the 'invoke' +instruction).
There are four different terminator instructions: the 'ret' instruction, the '
When the 'ret' instruction is executed, control flow returns back to
the calling function's context. If the instruction returns a value, that value
-shall be propogated into the calling function's data space.
+shall be propagated into the calling function's data space.
Example:
@@ -681,13 +682,19 @@ IfUnequal:
; Lookup indirect branch
switch uint <value>, label <defaultdest>, %switchtype <switchtable>
-
+
Overview:
+NOTE: The switch instruction may go away in the future. It is not very
+well supported in LLVM anyway, so don't go to great lengths to support it. Talk
+to Chris for more info if this concerns
+you.
+ The 'switch' instruction is used to transfer control flow to one of several different places. It is a generalization of the 'br' instruction, allowing a branch to occur to one of many possible destinations.
@@ -760,7 +767,7 @@ specified function, with the possibility of control flow transfer to either the 'normal label' label or the 'exception label'. The 'call' instruction is closely related, but guarantees that control flow either never returns from the called function, or that it -returns to the instruction succeeding the 'call' +returns to the instruction following the 'call' instruction.
-For a more comprehensive explanation of this instruction look in the llvm/docs/2001-05-18-ExceptionHandling.txt document.
+
@@ -807,48 +814,6 @@ For a more comprehensive explanation of this instruction look in the llvm/docs/2 - -
| -Unary Operations - |
- -There is only one unary operator: the 'not' instruction.
- - - -
- <result> = not <ty> <var> ; yields {ty}:result
-
-
-- -
- - -
- -
- <result> = xor bool true, <var> ; yields {bool}:result
-
-
-
- %x = not int 1 ; {int}:x is now equal to -2
- %x = not bool true ; {bool}:x is now equal to false
-
-
-
-
|
Binary Operations
@@ -874,10 +839,11 @@ There are several different binary operators: The 'add' instruction returns the sum of its two operands.
Arguments:-The two arguments to the 'add' instruction must be either integral or floating point values. Both arguments must have identical types.+The two arguments to the 'add' instruction must be either integer or floating point values. Both arguments must have identical types.
Semantics:-...+ +The value produced is the integer or floating point sum of the two operands.
Example:@@ -903,11 +869,13 @@ instruction present in most other intermediate representations.
|