Lexicon.rst 6.5 KB

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