1================ 2The LLVM Lexicon 3================ 4 5.. note:: 6 7 This document is a work in progress! 8 9Definitions 10=========== 11 12A 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 33B 34- 35 36.. _lexicon-bb-vectorization: 37 38**BB Vectorization** 39 Basic-Block Vectorization 40 41**BDCE** 42 Bit-tracking dead code elimination. Some bit-wise instructions (shifts, 43 ands, ors, etc.) "kill" some of their input bits -- that is, they make it 44 such that those bits can be either zero or one without affecting control or 45 data flow of a program. The BDCE pass removes instructions that only 46 compute these dead bits. 47 48**BURS** 49 Bottom Up Rewriting System --- A method of instruction selection for code 50 generation. An example is the `BURG 51 <http://www.program-transformation.org/Transform/BURG>`_ tool. 52 53C 54- 55 56**CFI** 57 Call Frame Information. Used in DWARF debug info and in C++ unwind info 58 to show how the function prolog lays out the stack frame. 59 60**CIE** 61 Common Information Entry. A kind of CFI used to reduce the size of FDEs. 62 The compiler creates a CIE which contains the information common across all 63 the FDEs. Each FDE then points to its CIE. 64 65**CSE** 66 Common Subexpression Elimination. An optimization that removes common 67 subexpression computation. For example ``(a+b)*(a+b)`` has two 68 subexpressions that are the same: ``(a+b)``. This optimization would 69 perform the addition only once and then perform the multiply (but only if 70 it's computationally correct/safe). 71 72D 73- 74 75**DAG** 76 Directed Acyclic Graph 77 78.. _derived pointer: 79.. _derived pointers: 80 81**Derived Pointer** 82 A pointer to the interior of an object, such that a garbage collector is 83 unable to use the pointer for reachability analysis. While a derived pointer 84 is live, the corresponding object pointer must be kept in a root, otherwise 85 the collector might free the referenced object. With copying collectors, 86 derived pointers pose an additional hazard that they may be invalidated at 87 any `safe point`_. This term is used in opposition to `object pointer`_. 88 89**DSA** 90 Data Structure Analysis 91 92**DSE** 93 Dead Store Elimination 94 95E 96- 97 98**ento** 99 This namespace houses the 100 `Clang Static Analyzer <https://clang.llvm.org/docs/ClangStaticAnalyzer.html>`_. 101 It is an abbreviaton of `entomology <https://en.wikipedia.org/wiki/Entomology>`_. 102 103 *"Entomology is the scientific study of insects."* 104 105 In the past, this namespace had not only the name `GR` (aka. Graph Reachability) 106 but also `entoSA`. 107 108F 109- 110 111**FCA** 112 First Class Aggregate 113 114**FDE** 115 Frame Description Entry. A kind of CFI used to describe the stack frame of 116 one function. 117 118G 119- 120 121**GC** 122 Garbage Collection. The practice of using reachability analysis instead of 123 explicit memory management to reclaim unused memory. 124 125**GEP** 126 ``GetElementPtr``. An LLVM IR instruction that is used to get the address 127 of a subelement of an aggregate data structure. It is documented in detail 128 `here <https://llvm.org/docs/GetElementPtr.html>`_. 129 130**GVN** 131 Global Value Numbering. GVN is a pass that partitions values computed by a 132 function into congruence classes. Values ending up in the same congruence 133 class are guaranteed to be the same for every execution of the program. 134 In that respect, congruency is a compile-time approximation of equivalence 135 of values at runtime. 136 137H 138- 139 140.. _heap: 141 142**Heap** 143 In garbage collection, the region of memory which is managed using 144 reachability analysis. 145 146I 147- 148 149**ICE** 150 Internal Compiler Error. This abbreviation is used to describe errors 151 that occur in LLVM or Clang as they are compiling source code. For example, 152 if a valid C++ source program were to trigger an assert in Clang when 153 compiled, that could be referred to as an "ICE". 154 155**IPA** 156 Inter-Procedural Analysis. Refers to any variety of code analysis that 157 occurs between procedures, functions or compilation units (modules). 158 159**IPO** 160 Inter-Procedural Optimization. Refers to any variety of code optimization 161 that occurs between procedures, functions or compilation units (modules). 162 163**ISel** 164 Instruction Selection 165 166L 167- 168 169**LCSSA** 170 Loop-Closed Static Single Assignment Form 171 172**LGTM** 173 "Looks Good To Me". In a review thread, this indicates that the 174 reviewer thinks that the patch is okay to commit. 175 176**LICM** 177 Loop Invariant Code Motion 178 179**LSDA** 180 Language Specific Data Area. C++ "zero cost" unwinding is built on top a 181 generic unwinding mechanism. As the unwinder walks each frame, it calls 182 a "personality" function to do language specific analysis. Each function's 183 FDE points to an optional LSDA which is passed to the personality function. 184 For C++, the LSDA contain info about the type and location of catch 185 statements in that function. 186 187**Load-VN** 188 Load Value Numbering 189 190**LTO** 191 Link-Time Optimization 192 193M 194- 195 196**MC** 197 Machine Code 198 199N 200- 201.. _nfc: 202 203**NFC** 204 "No functional change". Used in a commit message to indicate that a patch 205 is a pure refactoring/cleanup. 206 Usually used in the first line, so it is visible without opening the 207 actual commit email. 208 209O 210- 211.. _object pointer: 212.. _object pointers: 213 214**Object Pointer** 215 A pointer to an object such that the garbage collector is able to trace 216 references contained within the object. This term is used in opposition to 217 `derived pointer`_. 218 219P 220- 221 222**PR** 223 Problem report. A bug filed on `the LLVM Bug Tracking System 224 <https://bugs.llvm.org/enter_bug.cgi>`_. 225 226**PRE** 227 Partial Redundancy Elimination 228 229R 230- 231 232**RAUW** 233 234 Replace All Uses With. The functions ``User::replaceUsesOfWith()``, 235 ``Value::replaceAllUsesWith()``, and 236 ``Constant::replaceUsesOfWithOnConstant()`` implement the replacement of one 237 Value with another by iterating over its def/use chain and fixing up all of 238 the pointers to point to the new value. See 239 also `def/use chains <ProgrammersManual.html#iterating-over-def-use-use-def-chains>`_. 240 241**Reassociation** 242 Rearranging associative expressions to promote better redundancy elimination 243 and other optimization. For example, changing ``(A+B-A)`` into ``(B+A-A)``, 244 permitting it to be optimized into ``(B+0)`` then ``(B)``. 245 246**RFC** 247 Request for Comment. An email sent to a project mailing list in order to 248 solicit feedback on a proposed change. 249 250.. _roots: 251.. _stack roots: 252 253**Root** 254 In garbage collection, a pointer variable lying outside of the `heap`_ from 255 which the collector begins its reachability analysis. In the context of code 256 generation, "root" almost always refers to a "stack root" --- a local or 257 temporary variable within an executing function. 258 259**RPO** 260 Reverse postorder 261 262S 263- 264 265.. _safe point: 266 267**Safe Point** 268 In garbage collection, it is necessary to identify `stack roots`_ so that 269 reachability analysis may proceed. It may be infeasible to provide this 270 information for every instruction, so instead the information is 271 calculated only at designated safe points. With a copying collector, 272 `derived pointers`_ must not be retained across safe points and `object 273 pointers`_ must be reloaded from stack roots. 274 275**SDISel** 276 Selection DAG Instruction Selection. 277 278**SCC** 279 Strongly Connected Component 280 281**SCCP** 282 Sparse Conditional Constant Propagation 283 284**SLP** 285 Superword-Level Parallelism, same as :ref:`Basic-Block Vectorization 286 <lexicon-bb-vectorization>`. 287 288**Splat** 289 Splat refers to a vector of identical scalar elements. 290 291 The term is based on the PowerPC Altivec instructions that provided 292 this functionality in hardware. For example, "vsplth" and the corresponding 293 software intrinsic "vec_splat()". Examples of other hardware names for this 294 action include "duplicate" (ARM) and "broadcast" (x86). 295 296**SRoA** 297 Scalar Replacement of Aggregates 298 299**SSA** 300 Static Single Assignment 301 302**Stack Map** 303 In garbage collection, metadata emitted by the code generator which 304 identifies `roots`_ within the stack frame of an executing function. 305 306T 307- 308 309**TBAA** 310 Type-Based Alias Analysis 311 312