]>
Commit | Line | Data |
---|---|---|
c63539ff ML |
1 | .. |
2 | Copyright 1988-2022 Free Software Foundation, Inc. | |
3 | This is part of the GCC manual. | |
4 | For copying conditions, see the copyright.rst file. | |
5 | ||
6 | .. index:: Operands | |
7 | ||
8 | .. _operands: | |
9 | ||
10 | Operands | |
11 | ******** | |
12 | ||
13 | In general, expressions in GIMPLE consist of an operation and the | |
14 | appropriate number of simple operands; these operands must either be a | |
15 | GIMPLE rvalue (``is_gimple_val``), i.e. a constant or a register | |
16 | variable. More complex operands are factored out into temporaries, so | |
17 | that | |
18 | ||
19 | .. code-block:: c++ | |
20 | ||
21 | a = b + c + d | |
22 | ||
23 | becomes | |
24 | ||
25 | .. code-block:: c++ | |
26 | ||
27 | T1 = b + c; | |
28 | a = T1 + d; | |
29 | ||
30 | The same rule holds for arguments to a ``GIMPLE_CALL``. | |
31 | ||
32 | The target of an assignment is usually a variable, but can also be a | |
33 | ``MEM_REF`` or a compound lvalue as described below. | |
34 | ||
35 | .. toctree:: | |
36 | :maxdepth: 2 | |
37 | ||
38 | ||
39 | .. index:: Compound Expressions | |
40 | ||
41 | .. _compound-expressions: | |
42 | ||
43 | Compound Expressions | |
44 | ^^^^^^^^^^^^^^^^^^^^ | |
45 | ||
46 | The left-hand side of a C comma expression is simply moved into a separate | |
47 | statement. | |
48 | ||
49 | .. index:: Compound Lvalues | |
50 | ||
51 | .. _compound-lvalues: | |
52 | ||
53 | Compound Lvalues | |
54 | ^^^^^^^^^^^^^^^^ | |
55 | ||
56 | Currently compound lvalues involving array and structure field references | |
57 | are not broken down; an expression like ``a.b[2] = 42`` is not reduced | |
58 | any further (though complex array subscripts are). This restriction is a | |
59 | workaround for limitations in later optimizers; if we were to convert this | |
60 | to | |
61 | ||
62 | .. code-block:: c++ | |
63 | ||
64 | T1 = &a.b; | |
65 | T1[2] = 42; | |
66 | ||
67 | alias analysis would not remember that the reference to ``T1[2]`` came | |
68 | by way of ``a.b``, so it would think that the assignment could alias | |
69 | another member of ``a`` ; this broke ``struct-alias-1.c``. Future | |
70 | optimizer improvements may make this limitation unnecessary. | |
71 | ||
72 | .. index:: Conditional Expressions | |
73 | ||
74 | .. _conditional-expressions: | |
75 | ||
76 | Conditional Expressions | |
77 | ^^^^^^^^^^^^^^^^^^^^^^^ | |
78 | ||
79 | A C ``?:`` expression is converted into an ``if`` statement with | |
80 | each branch assigning to the same temporary. So, | |
81 | ||
82 | .. code-block:: c++ | |
83 | ||
84 | a = b ? c : d; | |
85 | ||
86 | becomes | |
87 | ||
88 | .. code-block:: c++ | |
89 | ||
90 | if (b == 1) | |
91 | T1 = c; | |
92 | else | |
93 | T1 = d; | |
94 | a = T1; | |
95 | ||
96 | The GIMPLE level if-conversion pass re-introduces ``?:`` | |
97 | expression, if appropriate. It is used to vectorize loops with | |
98 | conditions using vector conditional operations. | |
99 | ||
100 | Note that in GIMPLE, ``if`` statements are represented using | |
101 | ``GIMPLE_COND``, as described below. | |
102 | ||
103 | .. index:: Logical Operators | |
104 | ||
105 | .. _logical-operators: | |
106 | ||
107 | Logical Operators | |
108 | ^^^^^^^^^^^^^^^^^ | |
109 | ||
110 | Except when they appear in the condition operand of a | |
111 | ``GIMPLE_COND``, logical 'and' and 'or' operators are simplified | |
112 | as follows: ``a = b && c`` becomes | |
113 | ||
114 | .. code-block:: c++ | |
115 | ||
116 | T1 = (bool)b; | |
117 | if (T1 == true) | |
118 | T1 = (bool)c; | |
119 | a = T1; | |
120 | ||
121 | Note that ``T1`` in this example cannot be an expression temporary, | |
122 | because it has two different assignments. | |
123 | ||
124 | Manipulating operands | |
125 | ^^^^^^^^^^^^^^^^^^^^^ | |
126 | ||
127 | All gimple operands are of type ``tree``. But only certain | |
128 | types of trees are allowed to be used as operand tuples. Basic | |
129 | validation is controlled by the function | |
130 | ``get_gimple_rhs_class``, which given a tree code, returns an | |
131 | ``enum`` with the following values of type ``enum | |
132 | gimple_rhs_class`` | |
133 | ||
134 | * ``GIMPLE_INVALID_RHS`` | |
135 | The tree cannot be used as a GIMPLE operand. | |
136 | ||
137 | * ``GIMPLE_TERNARY_RHS`` | |
138 | The tree is a valid GIMPLE ternary operation. | |
139 | ||
140 | * ``GIMPLE_BINARY_RHS`` | |
141 | The tree is a valid GIMPLE binary operation. | |
142 | ||
143 | * ``GIMPLE_UNARY_RHS`` | |
144 | The tree is a valid GIMPLE unary operation. | |
145 | ||
146 | * ``GIMPLE_SINGLE_RHS`` | |
147 | The tree is a single object, that cannot be split into simpler | |
148 | operands (for instance, ``SSA_NAME``, ``VAR_DECL``, ``COMPONENT_REF``, etc). | |
149 | ||
150 | This operand class also acts as an escape hatch for tree nodes | |
151 | that may be flattened out into the operand vector, but would need | |
152 | more than two slots on the RHS. For instance, a ``COND_EXPR`` | |
153 | expression of the form ``(a op b) ? x : y`` could be flattened | |
154 | out on the operand vector using 4 slots, but it would also | |
155 | require additional processing to distinguish ``c = a op b`` | |
156 | from ``c = a op b ? x : y``. Something similar occurs with | |
157 | ``ASSERT_EXPR``. In time, these special case tree | |
158 | expressions should be flattened into the operand vector. | |
159 | ||
160 | For tree nodes in the categories ``GIMPLE_TERNARY_RHS``, | |
161 | ``GIMPLE_BINARY_RHS`` and ``GIMPLE_UNARY_RHS``, they cannot be | |
162 | stored inside tuples directly. They first need to be flattened and | |
163 | separated into individual components. For instance, given the GENERIC | |
164 | expression | |
165 | ||
166 | .. code-block:: c++ | |
167 | ||
168 | a = b + c | |
169 | ||
170 | its tree representation is: | |
171 | ||
172 | .. code-block:: c++ | |
173 | ||
174 | MODIFY_EXPR <VAR_DECL <a>, PLUS_EXPR <VAR_DECL <b>, VAR_DECL <c>>> | |
175 | ||
176 | In this case, the GIMPLE form for this statement is logically | |
177 | identical to its GENERIC form but in GIMPLE, the ``PLUS_EXPR`` | |
178 | on the RHS of the assignment is not represented as a tree, | |
179 | instead the two operands are taken out of the ``PLUS_EXPR`` sub-tree | |
180 | and flattened into the GIMPLE tuple as follows: | |
181 | ||
182 | .. code-block:: c++ | |
183 | ||
184 | GIMPLE_ASSIGN <PLUS_EXPR, VAR_DECL <a>, VAR_DECL <b>, VAR_DECL <c>> | |
185 | ||
186 | Operand vector allocation | |
187 | ^^^^^^^^^^^^^^^^^^^^^^^^^ | |
188 | ||
189 | The operand vector is stored at the bottom of the three tuple | |
190 | structures that accept operands. This means, that depending on | |
191 | the code of a given statement, its operand vector will be at | |
192 | different offsets from the base of the structure. To access | |
193 | tuple operands use the following accessors | |
194 | ||
195 | .. function:: unsigned gimple_num_ops (gimple g) | |
196 | ||
197 | Returns the number of operands in statement G. | |
198 | ||
199 | .. function:: tree gimple_op (gimple g, unsigned i) | |
200 | ||
201 | Returns operand ``I`` from statement ``G``. | |
202 | ||
203 | .. function:: tree * gimple_ops (gimple g) | |
204 | ||
205 | Returns a pointer into the operand vector for statement ``G``. This | |
206 | is computed using an internal table called ``gimple_ops_offset_`` []. | |
207 | This table is indexed by the gimple code of ``G``. | |
208 | ||
209 | When the compiler is built, this table is filled-in using the | |
210 | sizes of the structures used by each statement code defined in | |
211 | gimple.def. Since the operand vector is at the bottom of the | |
212 | structure, for a gimple code ``C`` the offset is computed as sizeof | |
213 | (struct-of ``C``) - sizeof (tree). | |
214 | ||
215 | This mechanism adds one memory indirection to every access when | |
216 | using ``gimple_op`` (), if this becomes a bottleneck, a pass can | |
217 | choose to memoize the result from ``gimple_ops`` () and use that to | |
218 | access the operands. | |
219 | ||
220 | Operand validation | |
221 | ^^^^^^^^^^^^^^^^^^ | |
222 | ||
223 | When adding a new operand to a gimple statement, the operand will | |
224 | be validated according to what each tuple accepts in its operand | |
225 | vector. These predicates are called by the | |
226 | ``gimple_name_set_...()``. Each tuple will use one of the | |
227 | following predicates (Note, this list is not exhaustive): | |
228 | ||
229 | .. function:: bool is_gimple_val (tree t) | |
230 | ||
231 | Returns true if t is a "GIMPLE value", which are all the | |
232 | non-addressable stack variables (variables for which | |
233 | ``is_gimple_reg`` returns true) and constants (expressions for which | |
234 | ``is_gimple_min_invariant`` returns true). | |
235 | ||
236 | .. function:: bool is_gimple_addressable (tree t) | |
237 | ||
238 | Returns true if t is a symbol or memory reference whose address | |
239 | can be taken. | |
240 | ||
241 | .. function:: bool is_gimple_asm_val (tree t) | |
242 | ||
243 | Similar to ``is_gimple_val`` but it also accepts hard registers. | |
244 | ||
245 | .. function:: bool is_gimple_call_addr (tree t) | |
246 | ||
247 | Return true if t is a valid expression to use as the function | |
248 | called by a ``GIMPLE_CALL``. | |
249 | ||
250 | .. function:: bool is_gimple_mem_ref_addr (tree t) | |
251 | ||
252 | Return true if t is a valid expression to use as first operand | |
253 | of a ``MEM_REF`` expression. | |
254 | ||
255 | .. function:: bool is_gimple_constant (tree t) | |
256 | ||
257 | Return true if t is a valid gimple constant. | |
258 | ||
259 | .. function:: bool is_gimple_min_invariant (tree t) | |
260 | ||
261 | Return true if t is a valid minimal invariant. This is different | |
262 | from constants, in that the specific value of t may not be known | |
263 | at compile time, but it is known that it doesn't change (e.g., | |
264 | the address of a function local variable). | |
265 | ||
266 | .. function:: bool is_gimple_ip_invariant (tree t) | |
267 | ||
268 | Return true if t is an interprocedural invariant. This means that t | |
269 | is a valid invariant in all functions (e.g. it can be an address of a | |
270 | global variable but not of a local one). | |
271 | ||
272 | .. function:: bool is_gimple_ip_invariant_address (tree t) | |
273 | ||
274 | Return true if t is an ``ADDR_EXPR`` that does not change once the | |
275 | program is running (and which is valid in all functions). | |
276 | ||
277 | Statement validation | |
278 | ^^^^^^^^^^^^^^^^^^^^ | |
279 | ||
280 | .. function:: bool is_gimple_assign (gimple g) | |
281 | ||
282 | Return true if the code of g is ``GIMPLE_ASSIGN``. | |
283 | ||
284 | .. function:: bool is_gimple_call (gimple g) | |
285 | ||
286 | Return true if the code of g is ``GIMPLE_CALL``. | |
287 | ||
288 | .. function:: bool is_gimple_debug (gimple g) | |
289 | ||
290 | Return true if the code of g is ``GIMPLE_DEBUG``. | |
291 | ||
292 | .. function:: bool gimple_assign_cast_p (const_gimple g) | |
293 | ||
294 | Return true if g is a ``GIMPLE_ASSIGN`` that performs a type cast | |
295 | operation. | |
296 | ||
297 | .. function:: bool gimple_debug_bind_p (gimple g) | |
298 | ||
299 | Return true if g is a ``GIMPLE_DEBUG`` that binds the value of an | |
300 | expression to a variable. | |
301 | ||
302 | .. function:: bool is_gimple_omp (gimple g) | |
303 | ||
304 | Return true if g is any of the OpenMP codes. | |
305 | ||
306 | .. function:: bool gimple_debug_begin_stmt_p (gimple g) | |
307 | ||
308 | Return true if g is a ``GIMPLE_DEBUG`` that marks the beginning of | |
309 | a source statement. | |
310 | ||
311 | .. function:: bool gimple_debug_inline_entry_p (gimple g) | |
312 | ||
313 | Return true if g is a ``GIMPLE_DEBUG`` that marks the entry | |
314 | point of an inlined function. | |
315 | ||
316 | .. function:: bool gimple_debug_nonbind_marker_p (gimple g) | |
317 | ||
318 | Return true if g is a ``GIMPLE_DEBUG`` that marks a program location, | |
3ed1b4ce | 319 | without any variable binding. |