xref: /llvm-project-15.0.7/llvm/docs/Lexicon.rst (revision 052d95a6)
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**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
46C
47-
48
49**CFI**
50    Call Frame Information. Used in DWARF debug info and in C++ unwind info
51    to show how the function prolog lays out the stack frame.
52
53**CIE**
54    Common Information Entry.  A kind of CFI used to reduce the size of FDEs.
55    The compiler creates a CIE which contains the information common across all
56    the FDEs.  Each FDE then points to its CIE.
57
58**CSE**
59    Common Subexpression Elimination. An optimization that removes common
60    subexpression compuation. For example ``(a+b)*(a+b)`` has two subexpressions
61    that are the same: ``(a+b)``. This optimization would perform the addition
62    only once and then perform the multiply (but only if it's computationally
63    correct/safe).
64
65D
66-
67
68**DAG**
69    Directed Acyclic Graph
70
71.. _derived pointer:
72.. _derived pointers:
73
74**Derived Pointer**
75    A pointer to the interior of an object, such that a garbage collector is
76    unable to use the pointer for reachability analysis. While a derived pointer
77    is live, the corresponding object pointer must be kept in a root, otherwise
78    the collector might free the referenced object. With copying collectors,
79    derived pointers pose an additional hazard that they may be invalidated at
80    any `safe point`_. This term is used in opposition to `object pointer`_.
81
82**DSA**
83    Data Structure Analysis
84
85**DSE**
86    Dead Store Elimination
87
88F
89-
90
91**FCA**
92    First Class Aggregate
93
94**FDE**
95    Frame Description Entry. A kind of CFI used to describe the stack frame of
96    one function.
97
98G
99-
100
101**GC**
102    Garbage Collection. The practice of using reachability analysis instead of
103    explicit memory management to reclaim unused memory.
104
105H
106-
107
108.. _heap:
109
110**Heap**
111    In garbage collection, the region of memory which is managed using
112    reachability analysis.
113
114I
115-
116
117**IPA**
118    Inter-Procedural Analysis. Refers to any variety of code analysis that
119    occurs between procedures, functions or compilation units (modules).
120
121**IPO**
122    Inter-Procedural Optimization. Refers to any variety of code optimization
123    that occurs between procedures, functions or compilation units (modules).
124
125**ISel**
126    Instruction Selection
127
128L
129-
130
131**LCSSA**
132    Loop-Closed Static Single Assignment Form
133
134**LGTM**
135    "Looks Good To Me". In a review thread, this indicates that the
136    reviewer thinks that the patch is okay to commit.
137
138**LICM**
139    Loop Invariant Code Motion
140
141**LSDA**
142    Language Specific Data Area.  C++ "zero cost" unwinding is built on top a
143    generic unwinding mechanism.  As the unwinder walks each frame, it calls
144    a "personality" function to do language specific analysis.  Each function's
145    FDE points to an optional LSDA which is passed to the personality function.
146    For C++, the LSDA contain info about the type and location of catch
147    statements in that function.
148
149**Load-VN**
150    Load Value Numbering
151
152**LTO**
153    Link-Time Optimization
154
155M
156-
157
158**MC**
159    Machine Code
160
161N
162-
163
164**NFC**
165  "No functional change". Used in a commit message to indicate that a patch
166  is a pure refactoring/cleanup.
167  Usually used in the first line, so it is visible without opening the
168  actual commit email.
169
170O
171-
172.. _object pointer:
173.. _object pointers:
174
175**Object Pointer**
176    A pointer to an object such that the garbage collector is able to trace
177    references contained within the object. This term is used in opposition to
178    `derived pointer`_.
179
180P
181-
182
183**PR**
184    Problem report. A bug filed on `the LLVM Bug Tracking System
185    <http://llvm.org/bugs/enter_bug.cgi>`_.
186
187**PRE**
188    Partial Redundancy Elimination
189
190R
191-
192
193**RAUW**
194
195    Replace All Uses With. The functions ``User::replaceUsesOfWith()``,
196    ``Value::replaceAllUsesWith()``, and
197    ``Constant::replaceUsesOfWithOnConstant()`` implement the replacement of one
198    Value with another by iterating over its def/use chain and fixing up all of
199    the pointers to point to the new value.  See
200    also `def/use chains <ProgrammersManual.html#iterating-over-def-use-use-def-chains>`_.
201
202**Reassociation**
203    Rearranging associative expressions to promote better redundancy elimination
204    and other optimization.  For example, changing ``(A+B-A)`` into ``(B+A-A)``,
205    permitting it to be optimized into ``(B+0)`` then ``(B)``.
206
207.. _roots:
208.. _stack roots:
209
210**Root**
211    In garbage collection, a pointer variable lying outside of the `heap`_ from
212    which the collector begins its reachability analysis. In the context of code
213    generation, "root" almost always refers to a "stack root" --- a local or
214    temporary variable within an executing function.
215
216**RPO**
217    Reverse postorder
218
219S
220-
221
222.. _safe point:
223
224**Safe Point**
225    In garbage collection, it is necessary to identify `stack roots`_ so that
226    reachability analysis may proceed. It may be infeasible to provide this
227    information for every instruction, so instead the information may is
228    calculated only at designated safe points. With a copying collector,
229    `derived pointers`_ must not be retained across safe points and `object
230    pointers`_ must be reloaded from stack roots.
231
232**SDISel**
233    Selection DAG Instruction Selection.
234
235**SCC**
236    Strongly Connected Component
237
238**SCCP**
239    Sparse Conditional Constant Propagation
240
241**SLP**
242    Superword-Level Parallelism, same as :ref:`Basic-Block Vectorization
243    <lexicon-bb-vectorization>`.
244
245**SRoA**
246    Scalar Replacement of Aggregates
247
248**SSA**
249    Static Single Assignment
250
251**Stack Map**
252    In garbage collection, metadata emitted by the code generator which
253    identifies `roots`_ within the stack frame of an executing function.
254
255T
256-
257
258**TBAA**
259    Type-Based Alias Analysis
260
261