docs/Lexicon.rst

   1 ================
   2 The LLVM Lexicon
   3 ================
   4
   5 .. note::
   6
   7     This document is a work in progress!
   8
   9 Definitions
  10 ===========
  11
  12 A
  13 -
  14
  15 **ADCE**
  16     Aggressive Dead Code Elimination
  17
  18 **AST**
  19     Abstract Syntax Tree.
  20
  21     Due to Clang's influence (mostly the fact that parsing and semantic
  22     analysis are so intertwined for C and especially C++), the typical
  23     working definition of AST in the LLVM community is roughly "the
  24     compiler's first complete symbolic (as opposed to textual)
  25     representation of an input program".
  26     As such, an "AST" might be a more general graph instead of a "tree"
  27     (consider the symbolic representation for the type of a typical "linked
  28     list node"). This working definition is closer to what some authors
  29     call an "annotated abstract syntax tree".
  30
  31     Consult your favorite compiler book or search engine for more details.
  32
  33 B
  34 -
  35
  36 .. _lexicon-bb-vectorization:
  37
  38 **BB Vectorization**
  39     Basic-Block Vectorization
  40
  41 **BURS**
  42     Bottom Up Rewriting System --- A method of instruction selection for code
  43     generation.  An example is the `BURG
  44     <http://www.program-transformation.org/Transform/BURG>`_ tool.
  45
  46 C
  47 -
  48
  49 **CSE**
  50     Common Subexpression Elimination. An optimization that removes common
  51     subexpression compuation. For example ``(a+b)*(a+b)`` has two subexpressions
  52     that are the same: ``(a+b)``. This optimization would perform the addition
  53     only once and then perform the multiply (but only if it's computationally
  54     correct/safe).
  55
  56 D
  57 -
  58
  59 **DAG**
  60     Directed Acyclic Graph
  61
  62 .. _derived pointer:
  63 .. _derived pointers:
  64
  65 **Derived Pointer**
  66     A pointer to the interior of an object, such that a garbage collector is
  67     unable to use the pointer for reachability analysis. While a derived pointer
  68     is live, the corresponding object pointer must be kept in a root, otherwise
  69     the collector might free the referenced object. With copying collectors,
  70     derived pointers pose an additional hazard that they may be invalidated at
  71     any `safe point`_. This term is used in opposition to `object pointer`_.
  72
  73 **DSA**
  74     Data Structure Analysis
  75
  76 **DSE**
  77     Dead Store Elimination
  78
  79 F
  80 -
  81
  82 **FCA**
  83     First Class Aggregate
  84
  85 G
  86 -
  87
  88 **GC**
  89     Garbage Collection. The practice of using reachability analysis instead of
  90     explicit memory management to reclaim unused memory.
  91
  92 H
  93 -
  94
  95 .. _heap:
  96
  97 **Heap**
  98     In garbage collection, the region of memory which is managed using
  99     reachability analysis.
 100
 101 I
 102 -
 103
 104 **IPA**
 105     Inter-Procedural Analysis. Refers to any variety of code analysis that
 106     occurs between procedures, functions or compilation units (modules).
 107
 108 **IPO**
 109     Inter-Procedural Optimization. Refers to any variety of code optimization
 110     that occurs between procedures, functions or compilation units (modules).
 111
 112 **ISel**
 113     Instruction Selection
 114
 115 L
 116 -
 117
 118 **LCSSA**
 119     Loop-Closed Static Single Assignment Form
 120
 121 **LICM**
 122     Loop Invariant Code Motion
 123
 124 **Load-VN**
 125     Load Value Numbering
 126
 127 **LTO**
 128     Link-Time Optimization
 129
 130 M
 131 -
 132
 133 **MC**
 134     Machine Code
 135
 136 N
 137 -
 138
 139 **NFC**
 140   "No functional change". Used in a commit message to indicate that a patch
 141   is a pure refactoring/cleanup.
 142   Usually used in the first line, so it is visible without opening the
 143   actual commit email.
 144
 145 O
 146 -
 147 .. _object pointer:
 148 .. _object pointers:
 149
 150 **Object Pointer**
 151     A pointer to an object such that the garbage collector is able to trace
 152     references contained within the object. This term is used in opposition to
 153     `derived pointer`_.
 154
 155 P
 156 -
 157
 158 **PRE**
 159     Partial Redundancy Elimination
 160
 161 R
 162 -
 163
 164 **RAUW**
 165
 166     Replace All Uses With. The functions ``User::replaceUsesOfWith()``,
 167     ``Value::replaceAllUsesWith()``, and
 168     ``Constant::replaceUsesOfWithOnConstant()`` implement the replacement of one
 169     Value with another by iterating over its def/use chain and fixing up all of
 170     the pointers to point to the new value.  See
 171     also `def/use chains <ProgrammersManual.html#iterating-over-def-use-use-def-chains>`_.
 172
 173 **Reassociation**
 174     Rearranging associative expressions to promote better redundancy elimination
 175     and other optimization.  For example, changing ``(A+B-A)`` into ``(B+A-A)``,
 176     permitting it to be optimized into ``(B+0)`` then ``(B)``.
 177
 178 .. _roots:
 179 .. _stack roots:
 180
 181 **Root**
 182     In garbage collection, a pointer variable lying outside of the `heap`_ from
 183     which the collector begins its reachability analysis. In the context of code
 184     generation, "root" almost always refers to a "stack root" --- a local or
 185     temporary variable within an executing function.
 186
 187 **RPO**
 188     Reverse postorder
 189
 190 S
 191 -
 192
 193 .. _safe point:
 194
 195 **Safe Point**
 196     In garbage collection, it is necessary to identify `stack roots`_ so that
 197     reachability analysis may proceed. It may be infeasible to provide this
 198     information for every instruction, so instead the information may is
 199     calculated only at designated safe points. With a copying collector,
 200     `derived pointers`_ must not be retained across safe points and `object
 201     pointers`_ must be reloaded from stack roots.
 202
 203 **SDISel**
 204     Selection DAG Instruction Selection.
 205
 206 **SCC**
 207     Strongly Connected Component
 208
 209 **SCCP**
 210     Sparse Conditional Constant Propagation
 211
 212 **SLP**
 213     Superword-Level Parallelism, same as :ref:`Basic-Block Vectorization
 214     <lexicon-bb-vectorization>`.
 215
 216 **SRoA**
 217     Scalar Replacement of Aggregates
 218
 219 **SSA**
 220     Static Single Assignment
 221
 222 **Stack Map**
 223     In garbage collection, metadata emitted by the code generator which
 224     identifies `roots`_ within the stack frame of an executing function.
 225
 226 T
 227 -
 228
 229 **TBAA**
 230     Type-Based Alias Analysis
 231