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 +LLVM is an Static Single Assignment (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.
The next two types of linkage are targeted for Microsoft Windows platform only. They are designed to support importing (exporting) symbols from (to) - DLLs. + DLLs (Dynamic Link Libraries).
A function definition contains a list of basic blocks, forming the CFG for +
A function definition contains a list of basic blocks, forming the CFG +(Control Flow Graph) 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 @@ -957,7 +959,7 @@ aspect of the data layout. The specifications accepted are as follows:
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 +optimizations to be performed on the intermediate representation 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 @@ -4515,7 +4518,8 @@ example, memory allocation.
LLVM support for Accurate Garbage -Collection requires the implementation and generation of these intrinsics. +Collection (GC) requires the implementation and generation of these +intrinsics. These intrinsics allow identification of GC roots on the stack, as well as garbage collector implementations that require read and write barriers. @@ -4867,11 +4871,12 @@ performance.
The 'llvm.pcmarker' intrinsic is a method to export a Program Counter -(PC) in a region of -code to simulators and other tools. The method is target specific, but it is -expected that the marker will use exported symbols to transmit the PC of the marker. -The marker makes no guarantees that it will remain with any specific instruction -after optimizations. It is possible that the presence of a marker will inhibit +(PC) in a region of +code to simulators and other tools. The method is target specific, but it is +expected that the marker will use exported symbols to transmit the PC of the +marker. +The marker makes no guarantees that it will remain with any specific instruction +after optimizations. It is possible that the presence of a marker will inhibit optimizations. The intended use is to be inserted after optimizations to allow correlations of simulation runs.
@@ -5691,7 +5696,8 @@ declare i8* @llvm.init.trampoline(i8* <tramp>, i8* <func>, i8* <n These intrinsic functions expand the "universal IR" of LLVM to represent hardware constructs for atomic operations and memory synchronization. This provides an interface to the hardware, not an interface to the programmer. It - is aimed at a low enough level to allow any programming models or APIs which + is aimed at a low enough level to allow any programming models or APIs + (Application Programming Interfaces) which need atomic behaviors to map cleanly onto it. It is also modeled primarily on hardware behavior. Just as hardware provides a "universal IR" for source languages, it also provides a starting point for developing a "universal"