1 | This is Info file gcc.info, produced by Makeinfo-1.55 from the input |
---|
2 | file gcc.texi. |
---|
3 | |
---|
4 | This file documents the use and the internals of the GNU compiler. |
---|
5 | |
---|
6 | Published by the Free Software Foundation 59 Temple Place - Suite 330 |
---|
7 | Boston, MA 02111-1307 USA |
---|
8 | |
---|
9 | Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995 Free Software |
---|
10 | Foundation, Inc. |
---|
11 | |
---|
12 | Permission is granted to make and distribute verbatim copies of this |
---|
13 | manual provided the copyright notice and this permission notice are |
---|
14 | preserved on all copies. |
---|
15 | |
---|
16 | Permission is granted to copy and distribute modified versions of |
---|
17 | this manual under the conditions for verbatim copying, provided also |
---|
18 | that the sections entitled "GNU General Public License," "Funding for |
---|
19 | Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are |
---|
20 | included exactly as in the original, and provided that the entire |
---|
21 | resulting derived work is distributed under the terms of a permission |
---|
22 | notice identical to this one. |
---|
23 | |
---|
24 | Permission is granted to copy and distribute translations of this |
---|
25 | manual into another language, under the above conditions for modified |
---|
26 | versions, except that the sections entitled "GNU General Public |
---|
27 | License," "Funding for Free Software," and "Protect Your Freedom--Fight |
---|
28 | `Look And Feel'", and this permission notice, may be included in |
---|
29 | translations approved by the Free Software Foundation instead of in the |
---|
30 | original English. |
---|
31 | |
---|
32 | |
---|
33 | File: gcc.info, Node: VMS Misc, Prev: Global Declarations, Up: VMS |
---|
34 | |
---|
35 | Other VMS Issues |
---|
36 | ================ |
---|
37 | |
---|
38 | GNU CC automatically arranges for `main' to return 1 by default if |
---|
39 | you fail to specify an explicit return value. This will be interpreted |
---|
40 | by VMS as a status code indicating a normal successful completion. |
---|
41 | Version 1 of GNU CC did not provide this default. |
---|
42 | |
---|
43 | GNU CC on VMS works only with the GNU assembler, GAS. You need |
---|
44 | version 1.37 or later of GAS in order to produce value debugging |
---|
45 | information for the VMS debugger. Use the ordinary VMS linker with the |
---|
46 | object files produced by GAS. |
---|
47 | |
---|
48 | Under previous versions of GNU CC, the generated code would |
---|
49 | occasionally give strange results when linked to the sharable `VAXCRTL' |
---|
50 | library. Now this should work. |
---|
51 | |
---|
52 | A caveat for use of `const' global variables: the `const' modifier |
---|
53 | must be specified in every external declaration of the variable in all |
---|
54 | of the source files that use that variable. Otherwise the linker will |
---|
55 | issue warnings about conflicting attributes for the variable. Your |
---|
56 | program will still work despite the warnings, but the variable will be |
---|
57 | placed in writable storage. |
---|
58 | |
---|
59 | Although the VMS linker does distinguish between upper and lower case |
---|
60 | letters in global symbols, most VMS compilers convert all such symbols |
---|
61 | into upper case and most run-time library routines also have upper case |
---|
62 | names. To be able to reliably call such routines, GNU CC (by means of |
---|
63 | the assembler GAS) converts global symbols into upper case like other |
---|
64 | VMS compilers. However, since the usual practice in C is to distinguish |
---|
65 | case, GNU CC (via GAS) tries to preserve usual C behavior by augmenting |
---|
66 | each name that is not all lower case. This means truncating the name |
---|
67 | to at most 23 characters and then adding more characters at the end |
---|
68 | which encode the case pattern of those 23. Names which contain at |
---|
69 | least one dollar sign are an exception; they are converted directly into |
---|
70 | upper case without augmentation. |
---|
71 | |
---|
72 | Name augmentation yields bad results for programs that use |
---|
73 | precompiled libraries (such as Xlib) which were generated by another |
---|
74 | compiler. You can use the compiler option `/NOCASE_HACK' to inhibit |
---|
75 | augmentation; it makes external C functions and variables |
---|
76 | case-independent as is usual on VMS. Alternatively, you could write |
---|
77 | all references to the functions and variables in such libraries using |
---|
78 | lower case; this will work on VMS, but is not portable to other |
---|
79 | systems. The compiler option `/NAMES' also provides control over |
---|
80 | global name handling. |
---|
81 | |
---|
82 | Function and variable names are handled somewhat differently with GNU |
---|
83 | C++. The GNU C++ compiler performs "name mangling" on function names, |
---|
84 | which means that it adds information to the function name to describe |
---|
85 | the data types of the arguments that the function takes. One result of |
---|
86 | this is that the name of a function can become very long. Since the |
---|
87 | VMS linker only recognizes the first 31 characters in a name, special |
---|
88 | action is taken to ensure that each function and variable has a unique |
---|
89 | name that can be represented in 31 characters. |
---|
90 | |
---|
91 | If the name (plus a name augmentation, if required) is less than 32 |
---|
92 | characters in length, then no special action is performed. If the name |
---|
93 | is longer than 31 characters, the assembler (GAS) will generate a hash |
---|
94 | string based upon the function name, truncate the function name to 23 |
---|
95 | characters, and append the hash string to the truncated name. If the |
---|
96 | `/VERBOSE' compiler option is used, the assembler will print both the |
---|
97 | full and truncated names of each symbol that is truncated. |
---|
98 | |
---|
99 | The `/NOCASE_HACK' compiler option should not be used when you are |
---|
100 | compiling programs that use libg++. libg++ has several instances of |
---|
101 | objects (i.e. `Filebuf' and `filebuf') which become indistinguishable |
---|
102 | in a case-insensitive environment. This leads to cases where you need |
---|
103 | to inhibit augmentation selectively (if you were using libg++ and Xlib |
---|
104 | in the same program, for example). There is no special feature for |
---|
105 | doing this, but you can get the result by defining a macro for each |
---|
106 | mixed case symbol for which you wish to inhibit augmentation. The |
---|
107 | macro should expand into the lower case equivalent of itself. For |
---|
108 | example: |
---|
109 | |
---|
110 | #define StuDlyCapS studlycaps |
---|
111 | |
---|
112 | These macro definitions can be placed in a header file to minimize |
---|
113 | the number of changes to your source code. |
---|
114 | |
---|
115 | |
---|
116 | File: gcc.info, Node: Portability, Next: Interface, Prev: VMS, Up: Top |
---|
117 | |
---|
118 | GNU CC and Portability |
---|
119 | ********************** |
---|
120 | |
---|
121 | The main goal of GNU CC was to make a good, fast compiler for |
---|
122 | machines in the class that the GNU system aims to run on: 32-bit |
---|
123 | machines that address 8-bit bytes and have several general registers. |
---|
124 | Elegance, theoretical power and simplicity are only secondary. |
---|
125 | |
---|
126 | GNU CC gets most of the information about the target machine from a |
---|
127 | machine description which gives an algebraic formula for each of the |
---|
128 | machine's instructions. This is a very clean way to describe the |
---|
129 | target. But when the compiler needs information that is difficult to |
---|
130 | express in this fashion, I have not hesitated to define an ad-hoc |
---|
131 | parameter to the machine description. The purpose of portability is to |
---|
132 | reduce the total work needed on the compiler; it was not of interest |
---|
133 | for its own sake. |
---|
134 | |
---|
135 | GNU CC does not contain machine dependent code, but it does contain |
---|
136 | code that depends on machine parameters such as endianness (whether the |
---|
137 | most significant byte has the highest or lowest address of the bytes in |
---|
138 | a word) and the availability of autoincrement addressing. In the |
---|
139 | RTL-generation pass, it is often necessary to have multiple strategies |
---|
140 | for generating code for a particular kind of syntax tree, strategies |
---|
141 | that are usable for different combinations of parameters. Often I have |
---|
142 | not tried to address all possible cases, but only the common ones or |
---|
143 | only the ones that I have encountered. As a result, a new target may |
---|
144 | require additional strategies. You will know if this happens because |
---|
145 | the compiler will call `abort'. Fortunately, the new strategies can be |
---|
146 | added in a machine-independent fashion, and will affect only the target |
---|
147 | machines that need them. |
---|
148 | |
---|
149 | |
---|
150 | File: gcc.info, Node: Interface, Next: Passes, Prev: Portability, Up: Top |
---|
151 | |
---|
152 | Interfacing to GNU CC Output |
---|
153 | **************************** |
---|
154 | |
---|
155 | GNU CC is normally configured to use the same function calling |
---|
156 | convention normally in use on the target system. This is done with the |
---|
157 | machine-description macros described (*note Target Macros::.). |
---|
158 | |
---|
159 | However, returning of structure and union values is done differently |
---|
160 | on some target machines. As a result, functions compiled with PCC |
---|
161 | returning such types cannot be called from code compiled with GNU CC, |
---|
162 | and vice versa. This does not cause trouble often because few Unix |
---|
163 | library routines return structures or unions. |
---|
164 | |
---|
165 | GNU CC code returns structures and unions that are 1, 2, 4 or 8 bytes |
---|
166 | long in the same registers used for `int' or `double' return values. |
---|
167 | (GNU CC typically allocates variables of such types in registers also.) |
---|
168 | Structures and unions of other sizes are returned by storing them into |
---|
169 | an address passed by the caller (usually in a register). The |
---|
170 | machine-description macros `STRUCT_VALUE' and `STRUCT_INCOMING_VALUE' |
---|
171 | tell GNU CC where to pass this address. |
---|
172 | |
---|
173 | By contrast, PCC on most target machines returns structures and |
---|
174 | unions of any size by copying the data into an area of static storage, |
---|
175 | and then returning the address of that storage as if it were a pointer |
---|
176 | value. The caller must copy the data from that memory area to the |
---|
177 | place where the value is wanted. This is slower than the method used |
---|
178 | by GNU CC, and fails to be reentrant. |
---|
179 | |
---|
180 | On some target machines, such as RISC machines and the 80386, the |
---|
181 | standard system convention is to pass to the subroutine the address of |
---|
182 | where to return the value. On these machines, GNU CC has been |
---|
183 | configured to be compatible with the standard compiler, when this method |
---|
184 | is used. It may not be compatible for structures of 1, 2, 4 or 8 bytes. |
---|
185 | |
---|
186 | GNU CC uses the system's standard convention for passing arguments. |
---|
187 | On some machines, the first few arguments are passed in registers; in |
---|
188 | others, all are passed on the stack. It would be possible to use |
---|
189 | registers for argument passing on any machine, and this would probably |
---|
190 | result in a significant speedup. But the result would be complete |
---|
191 | incompatibility with code that follows the standard convention. So this |
---|
192 | change is practical only if you are switching to GNU CC as the sole C |
---|
193 | compiler for the system. We may implement register argument passing on |
---|
194 | certain machines once we have a complete GNU system so that we can |
---|
195 | compile the libraries with GNU CC. |
---|
196 | |
---|
197 | On some machines (particularly the Sparc), certain types of arguments |
---|
198 | are passed "by invisible reference". This means that the value is |
---|
199 | stored in memory, and the address of the memory location is passed to |
---|
200 | the subroutine. |
---|
201 | |
---|
202 | If you use `longjmp', beware of automatic variables. ANSI C says |
---|
203 | that automatic variables that are not declared `volatile' have undefined |
---|
204 | values after a `longjmp'. And this is all GNU CC promises to do, |
---|
205 | because it is very difficult to restore register variables correctly, |
---|
206 | and one of GNU CC's features is that it can put variables in registers |
---|
207 | without your asking it to. |
---|
208 | |
---|
209 | If you want a variable to be unaltered by `longjmp', and you don't |
---|
210 | want to write `volatile' because old C compilers don't accept it, just |
---|
211 | take the address of the variable. If a variable's address is ever |
---|
212 | taken, even if just to compute it and ignore it, then the variable |
---|
213 | cannot go in a register: |
---|
214 | |
---|
215 | { |
---|
216 | int careful; |
---|
217 | &careful; |
---|
218 | ... |
---|
219 | } |
---|
220 | |
---|
221 | Code compiled with GNU CC may call certain library routines. Most of |
---|
222 | them handle arithmetic for which there are no instructions. This |
---|
223 | includes multiply and divide on some machines, and floating point |
---|
224 | operations on any machine for which floating point support is disabled |
---|
225 | with `-msoft-float'. Some standard parts of the C library, such as |
---|
226 | `bcopy' or `memcpy', are also called automatically. The usual function |
---|
227 | call interface is used for calling the library routines. |
---|
228 | |
---|
229 | These library routines should be defined in the library `libgcc.a', |
---|
230 | which GNU CC automatically searches whenever it links a program. On |
---|
231 | machines that have multiply and divide instructions, if hardware |
---|
232 | floating point is in use, normally `libgcc.a' is not needed, but it is |
---|
233 | searched just in case. |
---|
234 | |
---|
235 | Each arithmetic function is defined in `libgcc1.c' to use the |
---|
236 | corresponding C arithmetic operator. As long as the file is compiled |
---|
237 | with another C compiler, which supports all the C arithmetic operators, |
---|
238 | this file will work portably. However, `libgcc1.c' does not work if |
---|
239 | compiled with GNU CC, because each arithmetic function would compile |
---|
240 | into a call to itself! |
---|
241 | |
---|
242 | |
---|
243 | File: gcc.info, Node: Passes, Next: RTL, Prev: Interface, Up: Top |
---|
244 | |
---|
245 | Passes and Files of the Compiler |
---|
246 | ******************************** |
---|
247 | |
---|
248 | The overall control structure of the compiler is in `toplev.c'. This |
---|
249 | file is responsible for initialization, decoding arguments, opening and |
---|
250 | closing files, and sequencing the passes. |
---|
251 | |
---|
252 | The parsing pass is invoked only once, to parse the entire input. |
---|
253 | The RTL intermediate code for a function is generated as the function |
---|
254 | is parsed, a statement at a time. Each statement is read in as a |
---|
255 | syntax tree and then converted to RTL; then the storage for the tree |
---|
256 | for the statement is reclaimed. Storage for types (and the expressions |
---|
257 | for their sizes), declarations, and a representation of the binding |
---|
258 | contours and how they nest, remain until the function is finished being |
---|
259 | compiled; these are all needed to output the debugging information. |
---|
260 | |
---|
261 | Each time the parsing pass reads a complete function definition or |
---|
262 | top-level declaration, it calls either the function |
---|
263 | `rest_of_compilation', or the function `rest_of_decl_compilation' in |
---|
264 | `toplev.c', which are responsible for all further processing necessary, |
---|
265 | ending with output of the assembler language. All other compiler |
---|
266 | passes run, in sequence, within `rest_of_compilation'. When that |
---|
267 | function returns from compiling a function definition, the storage used |
---|
268 | for that function definition's compilation is entirely freed, unless it |
---|
269 | is an inline function (*note An Inline Function is As Fast As a Macro: |
---|
270 | Inline.). |
---|
271 | |
---|
272 | Here is a list of all the passes of the compiler and their source |
---|
273 | files. Also included is a description of where debugging dumps can be |
---|
274 | requested with `-d' options. |
---|
275 | |
---|
276 | * Parsing. This pass reads the entire text of a function definition, |
---|
277 | constructing partial syntax trees. This and RTL generation are no |
---|
278 | longer truly separate passes (formerly they were), but it is |
---|
279 | easier to think of them as separate. |
---|
280 | |
---|
281 | The tree representation does not entirely follow C syntax, because |
---|
282 | it is intended to support other languages as well. |
---|
283 | |
---|
284 | Language-specific data type analysis is also done in this pass, |
---|
285 | and every tree node that represents an expression has a data type |
---|
286 | attached. Variables are represented as declaration nodes. |
---|
287 | |
---|
288 | Constant folding and some arithmetic simplifications are also done |
---|
289 | during this pass. |
---|
290 | |
---|
291 | The language-independent source files for parsing are |
---|
292 | `stor-layout.c', `fold-const.c', and `tree.c'. There are also |
---|
293 | header files `tree.h' and `tree.def' which define the format of |
---|
294 | the tree representation. |
---|
295 | |
---|
296 | The source files to parse C are `c-parse.in', `c-decl.c', |
---|
297 | `c-typeck.c', `c-aux-info.c', `c-convert.c', and `c-lang.c' along |
---|
298 | with header files `c-lex.h', and `c-tree.h'. |
---|
299 | |
---|
300 | The source files for parsing C++ are `cp-parse.y', `cp-class.c', |
---|
301 | `cp-cvt.c', `cp-decl.c', `cp-decl2.c', `cp-dem.c', `cp-except.c', |
---|
302 | `cp-expr.c', `cp-init.c', `cp-lex.c', `cp-method.c', `cp-ptree.c', |
---|
303 | `cp-search.c', `cp-tree.c', `cp-type2.c', and `cp-typeck.c', along |
---|
304 | with header files `cp-tree.def', `cp-tree.h', and `cp-decl.h'. |
---|
305 | |
---|
306 | The special source files for parsing Objective C are |
---|
307 | `objc-parse.y', `objc-actions.c', `objc-tree.def', and |
---|
308 | `objc-actions.h'. Certain C-specific files are used for this as |
---|
309 | well. |
---|
310 | |
---|
311 | The file `c-common.c' is also used for all of the above languages. |
---|
312 | |
---|
313 | * RTL generation. This is the conversion of syntax tree into RTL |
---|
314 | code. It is actually done statement-by-statement during parsing, |
---|
315 | but for most purposes it can be thought of as a separate pass. |
---|
316 | |
---|
317 | This is where the bulk of target-parameter-dependent code is found, |
---|
318 | since often it is necessary for strategies to apply only when |
---|
319 | certain standard kinds of instructions are available. The purpose |
---|
320 | of named instruction patterns is to provide this information to |
---|
321 | the RTL generation pass. |
---|
322 | |
---|
323 | Optimization is done in this pass for `if'-conditions that are |
---|
324 | comparisons, boolean operations or conditional expressions. Tail |
---|
325 | recursion is detected at this time also. Decisions are made about |
---|
326 | how best to arrange loops and how to output `switch' statements. |
---|
327 | |
---|
328 | The source files for RTL generation include `stmt.c', `calls.c', |
---|
329 | `expr.c', `explow.c', `expmed.c', `function.c', `optabs.c' and |
---|
330 | `emit-rtl.c'. Also, the file `insn-emit.c', generated from the |
---|
331 | machine description by the program `genemit', is used in this |
---|
332 | pass. The header file `expr.h' is used for communication within |
---|
333 | this pass. |
---|
334 | |
---|
335 | The header files `insn-flags.h' and `insn-codes.h', generated from |
---|
336 | the machine description by the programs `genflags' and `gencodes', |
---|
337 | tell this pass which standard names are available for use and |
---|
338 | which patterns correspond to them. |
---|
339 | |
---|
340 | Aside from debugging information output, none of the following |
---|
341 | passes refers to the tree structure representation of the function |
---|
342 | (only part of which is saved). |
---|
343 | |
---|
344 | The decision of whether the function can and should be expanded |
---|
345 | inline in its subsequent callers is made at the end of rtl |
---|
346 | generation. The function must meet certain criteria, currently |
---|
347 | related to the size of the function and the types and number of |
---|
348 | parameters it has. Note that this function may contain loops, |
---|
349 | recursive calls to itself (tail-recursive functions can be |
---|
350 | inlined!), gotos, in short, all constructs supported by GNU CC. |
---|
351 | The file `integrate.c' contains the code to save a function's rtl |
---|
352 | for later inlining and to inline that rtl when the function is |
---|
353 | called. The header file `integrate.h' is also used for this |
---|
354 | purpose. |
---|
355 | |
---|
356 | The option `-dr' causes a debugging dump of the RTL code after |
---|
357 | this pass. This dump file's name is made by appending `.rtl' to |
---|
358 | the input file name. |
---|
359 | |
---|
360 | * Jump optimization. This pass simplifies jumps to the following |
---|
361 | instruction, jumps across jumps, and jumps to jumps. It deletes |
---|
362 | unreferenced labels and unreachable code, except that unreachable |
---|
363 | code that contains a loop is not recognized as unreachable in this |
---|
364 | pass. (Such loops are deleted later in the basic block analysis.) |
---|
365 | It also converts some code originally written with jumps into |
---|
366 | sequences of instructions that directly set values from the |
---|
367 | results of comparisons, if the machine has such instructions. |
---|
368 | |
---|
369 | Jump optimization is performed two or three times. The first time |
---|
370 | is immediately following RTL generation. The second time is after |
---|
371 | CSE, but only if CSE says repeated jump optimization is needed. |
---|
372 | The last time is right before the final pass. That time, |
---|
373 | cross-jumping and deletion of no-op move instructions are done |
---|
374 | together with the optimizations described above. |
---|
375 | |
---|
376 | The source file of this pass is `jump.c'. |
---|
377 | |
---|
378 | The option `-dj' causes a debugging dump of the RTL code after |
---|
379 | this pass is run for the first time. This dump file's name is |
---|
380 | made by appending `.jump' to the input file name. |
---|
381 | |
---|
382 | * Register scan. This pass finds the first and last use of each |
---|
383 | register, as a guide for common subexpression elimination. Its |
---|
384 | source is in `regclass.c'. |
---|
385 | |
---|
386 | * Jump threading. This pass detects a condition jump that branches |
---|
387 | to an identical or inverse test. Such jumps can be `threaded' |
---|
388 | through the second conditional test. The source code for this |
---|
389 | pass is in `jump.c'. This optimization is only performed if |
---|
390 | `-fthread-jumps' is enabled. |
---|
391 | |
---|
392 | * Common subexpression elimination. This pass also does constant |
---|
393 | propagation. Its source file is `cse.c'. If constant propagation |
---|
394 | causes conditional jumps to become unconditional or to become |
---|
395 | no-ops, jump optimization is run again when CSE is finished. |
---|
396 | |
---|
397 | The option `-ds' causes a debugging dump of the RTL code after |
---|
398 | this pass. This dump file's name is made by appending `.cse' to |
---|
399 | the input file name. |
---|
400 | |
---|
401 | * Loop optimization. This pass moves constant expressions out of |
---|
402 | loops, and optionally does strength-reduction and loop unrolling |
---|
403 | as well. Its source files are `loop.c' and `unroll.c', plus the |
---|
404 | header `loop.h' used for communication between them. Loop |
---|
405 | unrolling uses some functions in `integrate.c' and the header |
---|
406 | `integrate.h'. |
---|
407 | |
---|
408 | The option `-dL' causes a debugging dump of the RTL code after |
---|
409 | this pass. This dump file's name is made by appending `.loop' to |
---|
410 | the input file name. |
---|
411 | |
---|
412 | * If `-frerun-cse-after-loop' was enabled, a second common |
---|
413 | subexpression elimination pass is performed after the loop |
---|
414 | optimization pass. Jump threading is also done again at this time |
---|
415 | if it was specified. |
---|
416 | |
---|
417 | The option `-dt' causes a debugging dump of the RTL code after |
---|
418 | this pass. This dump file's name is made by appending `.cse2' to |
---|
419 | the input file name. |
---|
420 | |
---|
421 | * Stupid register allocation is performed at this point in a |
---|
422 | nonoptimizing compilation. It does a little data flow analysis as |
---|
423 | well. When stupid register allocation is in use, the next pass |
---|
424 | executed is the reloading pass; the others in between are skipped. |
---|
425 | The source file is `stupid.c'. |
---|
426 | |
---|
427 | * Data flow analysis (`flow.c'). This pass divides the program into |
---|
428 | basic blocks (and in the process deletes unreachable loops); then |
---|
429 | it computes which pseudo-registers are live at each point in the |
---|
430 | program, and makes the first instruction that uses a value point at |
---|
431 | the instruction that computed the value. |
---|
432 | |
---|
433 | This pass also deletes computations whose results are never used, |
---|
434 | and combines memory references with add or subtract instructions |
---|
435 | to make autoincrement or autodecrement addressing. |
---|
436 | |
---|
437 | The option `-df' causes a debugging dump of the RTL code after |
---|
438 | this pass. This dump file's name is made by appending `.flow' to |
---|
439 | the input file name. If stupid register allocation is in use, this |
---|
440 | dump file reflects the full results of such allocation. |
---|
441 | |
---|
442 | * Instruction combination (`combine.c'). This pass attempts to |
---|
443 | combine groups of two or three instructions that are related by |
---|
444 | data flow into single instructions. It combines the RTL |
---|
445 | expressions for the instructions by substitution, simplifies the |
---|
446 | result using algebra, and then attempts to match the result |
---|
447 | against the machine description. |
---|
448 | |
---|
449 | The option `-dc' causes a debugging dump of the RTL code after |
---|
450 | this pass. This dump file's name is made by appending `.combine' |
---|
451 | to the input file name. |
---|
452 | |
---|
453 | * Instruction scheduling (`sched.c'). This pass looks for |
---|
454 | instructions whose output will not be available by the time that |
---|
455 | it is used in subsequent instructions. (Memory loads and floating |
---|
456 | point instructions often have this behavior on RISC machines). It |
---|
457 | re-orders instructions within a basic block to try to separate the |
---|
458 | definition and use of items that otherwise would cause pipeline |
---|
459 | stalls. |
---|
460 | |
---|
461 | Instruction scheduling is performed twice. The first time is |
---|
462 | immediately after instruction combination and the second is |
---|
463 | immediately after reload. |
---|
464 | |
---|
465 | The option `-dS' causes a debugging dump of the RTL code after this |
---|
466 | pass is run for the first time. The dump file's name is made by |
---|
467 | appending `.sched' to the input file name. |
---|
468 | |
---|
469 | * Register class preferencing. The RTL code is scanned to find out |
---|
470 | which register class is best for each pseudo register. The source |
---|
471 | file is `regclass.c'. |
---|
472 | |
---|
473 | * Local register allocation (`local-alloc.c'). This pass allocates |
---|
474 | hard registers to pseudo registers that are used only within one |
---|
475 | basic block. Because the basic block is linear, it can use fast |
---|
476 | and powerful techniques to do a very good job. |
---|
477 | |
---|
478 | The option `-dl' causes a debugging dump of the RTL code after |
---|
479 | this pass. This dump file's name is made by appending `.lreg' to |
---|
480 | the input file name. |
---|
481 | |
---|
482 | * Global register allocation (`global.c'). This pass allocates hard |
---|
483 | registers for the remaining pseudo registers (those whose life |
---|
484 | spans are not contained in one basic block). |
---|
485 | |
---|
486 | * Reloading. This pass renumbers pseudo registers with the hardware |
---|
487 | registers numbers they were allocated. Pseudo registers that did |
---|
488 | not get hard registers are replaced with stack slots. Then it |
---|
489 | finds instructions that are invalid because a value has failed to |
---|
490 | end up in a register, or has ended up in a register of the wrong |
---|
491 | kind. It fixes up these instructions by reloading the |
---|
492 | problematical values temporarily into registers. Additional |
---|
493 | instructions are generated to do the copying. |
---|
494 | |
---|
495 | The reload pass also optionally eliminates the frame pointer and |
---|
496 | inserts instructions to save and restore call-clobbered registers |
---|
497 | around calls. |
---|
498 | |
---|
499 | Source files are `reload.c' and `reload1.c', plus the header |
---|
500 | `reload.h' used for communication between them. |
---|
501 | |
---|
502 | The option `-dg' causes a debugging dump of the RTL code after |
---|
503 | this pass. This dump file's name is made by appending `.greg' to |
---|
504 | the input file name. |
---|
505 | |
---|
506 | * Instruction scheduling is repeated here to try to avoid pipeline |
---|
507 | stalls due to memory loads generated for spilled pseudo registers. |
---|
508 | |
---|
509 | The option `-dR' causes a debugging dump of the RTL code after |
---|
510 | this pass. This dump file's name is made by appending `.sched2' |
---|
511 | to the input file name. |
---|
512 | |
---|
513 | * Jump optimization is repeated, this time including cross-jumping |
---|
514 | and deletion of no-op move instructions. |
---|
515 | |
---|
516 | The option `-dJ' causes a debugging dump of the RTL code after |
---|
517 | this pass. This dump file's name is made by appending `.jump2' to |
---|
518 | the input file name. |
---|
519 | |
---|
520 | * Delayed branch scheduling. This optional pass attempts to find |
---|
521 | instructions that can go into the delay slots of other |
---|
522 | instructions, usually jumps and calls. The source file name is |
---|
523 | `reorg.c'. |
---|
524 | |
---|
525 | The option `-dd' causes a debugging dump of the RTL code after |
---|
526 | this pass. This dump file's name is made by appending `.dbr' to |
---|
527 | the input file name. |
---|
528 | |
---|
529 | * Conversion from usage of some hard registers to usage of a register |
---|
530 | stack may be done at this point. Currently, this is supported only |
---|
531 | for the floating-point registers of the Intel 80387 coprocessor. |
---|
532 | The source file name is `reg-stack.c'. |
---|
533 | |
---|
534 | The options `-dk' causes a debugging dump of the RTL code after |
---|
535 | this pass. This dump file's name is made by appending `.stack' to |
---|
536 | the input file name. |
---|
537 | |
---|
538 | * Final. This pass outputs the assembler code for the function. It |
---|
539 | is also responsible for identifying spurious test and compare |
---|
540 | instructions. Machine-specific peephole optimizations are |
---|
541 | performed at the same time. The function entry and exit sequences |
---|
542 | are generated directly as assembler code in this pass; they never |
---|
543 | exist as RTL. |
---|
544 | |
---|
545 | The source files are `final.c' plus `insn-output.c'; the latter is |
---|
546 | generated automatically from the machine description by the tool |
---|
547 | `genoutput'. The header file `conditions.h' is used for |
---|
548 | communication between these files. |
---|
549 | |
---|
550 | * Debugging information output. This is run after final because it |
---|
551 | must output the stack slot offsets for pseudo registers that did |
---|
552 | not get hard registers. Source files are `dbxout.c' for DBX |
---|
553 | symbol table format, `sdbout.c' for SDB symbol table format, and |
---|
554 | `dwarfout.c' for DWARF symbol table format. |
---|
555 | |
---|
556 | Some additional files are used by all or many passes: |
---|
557 | |
---|
558 | * Every pass uses `machmode.def' and `machmode.h' which define the |
---|
559 | machine modes. |
---|
560 | |
---|
561 | * Several passes use `real.h', which defines the default |
---|
562 | representation of floating point constants and how to operate on |
---|
563 | them. |
---|
564 | |
---|
565 | * All the passes that work with RTL use the header files `rtl.h' and |
---|
566 | `rtl.def', and subroutines in file `rtl.c'. The tools `gen*' also |
---|
567 | use these files to read and work with the machine description RTL. |
---|
568 | |
---|
569 | * Several passes refer to the header file `insn-config.h' which |
---|
570 | contains a few parameters (C macro definitions) generated |
---|
571 | automatically from the machine description RTL by the tool |
---|
572 | `genconfig'. |
---|
573 | |
---|
574 | * Several passes use the instruction recognizer, which consists of |
---|
575 | `recog.c' and `recog.h', plus the files `insn-recog.c' and |
---|
576 | `insn-extract.c' that are generated automatically from the machine |
---|
577 | description by the tools `genrecog' and `genextract'. |
---|
578 | |
---|
579 | * Several passes use the header files `regs.h' which defines the |
---|
580 | information recorded about pseudo register usage, and |
---|
581 | `basic-block.h' which defines the information recorded about basic |
---|
582 | blocks. |
---|
583 | |
---|
584 | * `hard-reg-set.h' defines the type `HARD_REG_SET', a bit-vector |
---|
585 | with a bit for each hard register, and some macros to manipulate |
---|
586 | it. This type is just `int' if the machine has few enough hard |
---|
587 | registers; otherwise it is an array of `int' and some of the |
---|
588 | macros expand into loops. |
---|
589 | |
---|
590 | * Several passes use instruction attributes. A definition of the |
---|
591 | attributes defined for a particular machine is in file |
---|
592 | `insn-attr.h', which is generated from the machine description by |
---|
593 | the program `genattr'. The file `insn-attrtab.c' contains |
---|
594 | subroutines to obtain the attribute values for insns. It is |
---|
595 | generated from the machine description by the program `genattrtab'. |
---|
596 | |
---|
597 | |
---|
598 | File: gcc.info, Node: RTL, Next: Machine Desc, Prev: Passes, Up: Top |
---|
599 | |
---|
600 | RTL Representation |
---|
601 | ****************** |
---|
602 | |
---|
603 | Most of the work of the compiler is done on an intermediate |
---|
604 | representation called register transfer language. In this language, |
---|
605 | the instructions to be output are described, pretty much one by one, in |
---|
606 | an algebraic form that describes what the instruction does. |
---|
607 | |
---|
608 | RTL is inspired by Lisp lists. It has both an internal form, made |
---|
609 | up of structures that point at other structures, and a textual form |
---|
610 | that is used in the machine description and in printed debugging dumps. |
---|
611 | The textual form uses nested parentheses to indicate the pointers in |
---|
612 | the internal form. |
---|
613 | |
---|
614 | * Menu: |
---|
615 | |
---|
616 | * RTL Objects:: Expressions vs vectors vs strings vs integers. |
---|
617 | * Accessors:: Macros to access expression operands or vector elts. |
---|
618 | * Flags:: Other flags in an RTL expression. |
---|
619 | * Machine Modes:: Describing the size and format of a datum. |
---|
620 | * Constants:: Expressions with constant values. |
---|
621 | * Regs and Memory:: Expressions representing register contents or memory. |
---|
622 | * Arithmetic:: Expressions representing arithmetic on other expressions. |
---|
623 | * Comparisons:: Expressions representing comparison of expressions. |
---|
624 | * Bit Fields:: Expressions representing bitfields in memory or reg. |
---|
625 | * Conversions:: Extending, truncating, floating or fixing. |
---|
626 | * RTL Declarations:: Declaring volatility, constancy, etc. |
---|
627 | * Side Effects:: Expressions for storing in registers, etc. |
---|
628 | * Incdec:: Embedded side-effects for autoincrement addressing. |
---|
629 | * Assembler:: Representing `asm' with operands. |
---|
630 | * Insns:: Expression types for entire insns. |
---|
631 | * Calls:: RTL representation of function call insns. |
---|
632 | * Sharing:: Some expressions are unique; others *must* be copied. |
---|
633 | * Reading RTL:: Reading textual RTL from a file. |
---|
634 | |
---|
635 | |
---|
636 | File: gcc.info, Node: RTL Objects, Next: Accessors, Prev: RTL, Up: RTL |
---|
637 | |
---|
638 | RTL Object Types |
---|
639 | ================ |
---|
640 | |
---|
641 | RTL uses five kinds of objects: expressions, integers, wide integers, |
---|
642 | strings and vectors. Expressions are the most important ones. An RTL |
---|
643 | expression ("RTX", for short) is a C structure, but it is usually |
---|
644 | referred to with a pointer; a type that is given the typedef name `rtx'. |
---|
645 | |
---|
646 | An integer is simply an `int'; their written form uses decimal |
---|
647 | digits. A wide integer is an integral object whose type is |
---|
648 | `HOST_WIDE_INT' (*note Config::.); their written form uses decimal |
---|
649 | digits. |
---|
650 | |
---|
651 | A string is a sequence of characters. In core it is represented as a |
---|
652 | `char *' in usual C fashion, and it is written in C syntax as well. |
---|
653 | However, strings in RTL may never be null. If you write an empty |
---|
654 | string in a machine description, it is represented in core as a null |
---|
655 | pointer rather than as a pointer to a null character. In certain |
---|
656 | contexts, these null pointers instead of strings are valid. Within RTL |
---|
657 | code, strings are most commonly found inside `symbol_ref' expressions, |
---|
658 | but they appear in other contexts in the RTL expressions that make up |
---|
659 | machine descriptions. |
---|
660 | |
---|
661 | A vector contains an arbitrary number of pointers to expressions. |
---|
662 | The number of elements in the vector is explicitly present in the |
---|
663 | vector. The written form of a vector consists of square brackets |
---|
664 | (`[...]') surrounding the elements, in sequence and with whitespace |
---|
665 | separating them. Vectors of length zero are not created; null pointers |
---|
666 | are used instead. |
---|
667 | |
---|
668 | Expressions are classified by "expression codes" (also called RTX |
---|
669 | codes). The expression code is a name defined in `rtl.def', which is |
---|
670 | also (in upper case) a C enumeration constant. The possible expression |
---|
671 | codes and their meanings are machine-independent. The code of an RTX |
---|
672 | can be extracted with the macro `GET_CODE (X)' and altered with |
---|
673 | `PUT_CODE (X, NEWCODE)'. |
---|
674 | |
---|
675 | The expression code determines how many operands the expression |
---|
676 | contains, and what kinds of objects they are. In RTL, unlike Lisp, you |
---|
677 | cannot tell by looking at an operand what kind of object it is. |
---|
678 | Instead, you must know from its context--from the expression code of |
---|
679 | the containing expression. For example, in an expression of code |
---|
680 | `subreg', the first operand is to be regarded as an expression and the |
---|
681 | second operand as an integer. In an expression of code `plus', there |
---|
682 | are two operands, both of which are to be regarded as expressions. In |
---|
683 | a `symbol_ref' expression, there is one operand, which is to be |
---|
684 | regarded as a string. |
---|
685 | |
---|
686 | Expressions are written as parentheses containing the name of the |
---|
687 | expression type, its flags and machine mode if any, and then the |
---|
688 | operands of the expression (separated by spaces). |
---|
689 | |
---|
690 | Expression code names in the `md' file are written in lower case, |
---|
691 | but when they appear in C code they are written in upper case. In this |
---|
692 | manual, they are shown as follows: `const_int'. |
---|
693 | |
---|
694 | In a few contexts a null pointer is valid where an expression is |
---|
695 | normally wanted. The written form of this is `(nil)'. |
---|
696 | |
---|
697 | |
---|
698 | File: gcc.info, Node: Accessors, Next: Flags, Prev: RTL Objects, Up: RTL |
---|
699 | |
---|
700 | Access to Operands |
---|
701 | ================== |
---|
702 | |
---|
703 | For each expression type `rtl.def' specifies the number of contained |
---|
704 | objects and their kinds, with four possibilities: `e' for expression |
---|
705 | (actually a pointer to an expression), `i' for integer, `w' for wide |
---|
706 | integer, `s' for string, and `E' for vector of expressions. The |
---|
707 | sequence of letters for an expression code is called its "format". |
---|
708 | Thus, the format of `subreg' is `ei'. |
---|
709 | |
---|
710 | A few other format characters are used occasionally: |
---|
711 | |
---|
712 | `u' |
---|
713 | `u' is equivalent to `e' except that it is printed differently in |
---|
714 | debugging dumps. It is used for pointers to insns. |
---|
715 | |
---|
716 | `n' |
---|
717 | `n' is equivalent to `i' except that it is printed differently in |
---|
718 | debugging dumps. It is used for the line number or code number of |
---|
719 | a `note' insn. |
---|
720 | |
---|
721 | `S' |
---|
722 | `S' indicates a string which is optional. In the RTL objects in |
---|
723 | core, `S' is equivalent to `s', but when the object is read, from |
---|
724 | an `md' file, the string value of this operand may be omitted. An |
---|
725 | omitted string is taken to be the null string. |
---|
726 | |
---|
727 | `V' |
---|
728 | `V' indicates a vector which is optional. In the RTL objects in |
---|
729 | core, `V' is equivalent to `E', but when the object is read from |
---|
730 | an `md' file, the vector value of this operand may be omitted. An |
---|
731 | omitted vector is effectively the same as a vector of no elements. |
---|
732 | |
---|
733 | `0' |
---|
734 | `0' means a slot whose contents do not fit any normal category. |
---|
735 | `0' slots are not printed at all in dumps, and are often used in |
---|
736 | special ways by small parts of the compiler. |
---|
737 | |
---|
738 | There are macros to get the number of operands, the format, and the |
---|
739 | class of an expression code: |
---|
740 | |
---|
741 | `GET_RTX_LENGTH (CODE)' |
---|
742 | Number of operands of an RTX of code CODE. |
---|
743 | |
---|
744 | `GET_RTX_FORMAT (CODE)' |
---|
745 | The format of an RTX of code CODE, as a C string. |
---|
746 | |
---|
747 | `GET_RTX_CLASS (CODE)' |
---|
748 | A single character representing the type of RTX operation that code |
---|
749 | CODE performs. |
---|
750 | |
---|
751 | The following classes are defined: |
---|
752 | |
---|
753 | `o' |
---|
754 | An RTX code that represents an actual object, such as `reg' or |
---|
755 | `mem'. `subreg' is not in this class. |
---|
756 | |
---|
757 | `<' |
---|
758 | An RTX code for a comparison. The codes in this class are |
---|
759 | `NE', `EQ', `LE', `LT', `GE', `GT', `LEU', `LTU', `GEU', |
---|
760 | `GTU'. |
---|
761 | |
---|
762 | `1' |
---|
763 | An RTX code for a unary arithmetic operation, such as `neg'. |
---|
764 | |
---|
765 | `c' |
---|
766 | An RTX code for a commutative binary operation, other than |
---|
767 | `NE' and `EQ' (which have class `<'). |
---|
768 | |
---|
769 | `2' |
---|
770 | An RTX code for a noncommutative binary operation, such as |
---|
771 | `MINUS'. |
---|
772 | |
---|
773 | `b' |
---|
774 | An RTX code for a bitfield operation, either `ZERO_EXTRACT' or |
---|
775 | `SIGN_EXTRACT'. |
---|
776 | |
---|
777 | `3' |
---|
778 | An RTX code for other three input operations, such as |
---|
779 | `IF_THEN_ELSE'. |
---|
780 | |
---|
781 | `i' |
---|
782 | An RTX code for a machine insn (`INSN', `JUMP_INSN', and |
---|
783 | `CALL_INSN'). |
---|
784 | |
---|
785 | `m' |
---|
786 | An RTX code for something that matches in insns, such as |
---|
787 | `MATCH_DUP'. |
---|
788 | |
---|
789 | `x' |
---|
790 | All other RTX codes. |
---|
791 | |
---|
792 | Operands of expressions are accessed using the macros `XEXP', |
---|
793 | `XINT', `XWINT' and `XSTR'. Each of these macros takes two arguments: |
---|
794 | an expression-pointer (RTX) and an operand number (counting from zero). |
---|
795 | Thus, |
---|
796 | |
---|
797 | XEXP (X, 2) |
---|
798 | |
---|
799 | accesses operand 2 of expression X, as an expression. |
---|
800 | |
---|
801 | XINT (X, 2) |
---|
802 | |
---|
803 | accesses the same operand as an integer. `XSTR', used in the same |
---|
804 | fashion, would access it as a string. |
---|
805 | |
---|
806 | Any operand can be accessed as an integer, as an expression or as a |
---|
807 | string. You must choose the correct method of access for the kind of |
---|
808 | value actually stored in the operand. You would do this based on the |
---|
809 | expression code of the containing expression. That is also how you |
---|
810 | would know how many operands there are. |
---|
811 | |
---|
812 | For example, if X is a `subreg' expression, you know that it has two |
---|
813 | operands which can be correctly accessed as `XEXP (X, 0)' and `XINT (X, |
---|
814 | 1)'. If you did `XINT (X, 0)', you would get the address of the |
---|
815 | expression operand but cast as an integer; that might occasionally be |
---|
816 | useful, but it would be cleaner to write `(int) XEXP (X, 0)'. `XEXP |
---|
817 | (X, 1)' would also compile without error, and would return the second, |
---|
818 | integer operand cast as an expression pointer, which would probably |
---|
819 | result in a crash when accessed. Nothing stops you from writing `XEXP |
---|
820 | (X, 28)' either, but this will access memory past the end of the |
---|
821 | expression with unpredictable results. |
---|
822 | |
---|
823 | Access to operands which are vectors is more complicated. You can |
---|
824 | use the macro `XVEC' to get the vector-pointer itself, or the macros |
---|
825 | `XVECEXP' and `XVECLEN' to access the elements and length of a vector. |
---|
826 | |
---|
827 | `XVEC (EXP, IDX)' |
---|
828 | Access the vector-pointer which is operand number IDX in EXP. |
---|
829 | |
---|
830 | `XVECLEN (EXP, IDX)' |
---|
831 | Access the length (number of elements) in the vector which is in |
---|
832 | operand number IDX in EXP. This value is an `int'. |
---|
833 | |
---|
834 | `XVECEXP (EXP, IDX, ELTNUM)' |
---|
835 | Access element number ELTNUM in the vector which is in operand |
---|
836 | number IDX in EXP. This value is an RTX. |
---|
837 | |
---|
838 | It is up to you to make sure that ELTNUM is not negative and is |
---|
839 | less than `XVECLEN (EXP, IDX)'. |
---|
840 | |
---|
841 | All the macros defined in this section expand into lvalues and |
---|
842 | therefore can be used to assign the operands, lengths and vector |
---|
843 | elements as well as to access them. |
---|
844 | |
---|
845 | |
---|
846 | File: gcc.info, Node: Flags, Next: Machine Modes, Prev: Accessors, Up: RTL |
---|
847 | |
---|
848 | Flags in an RTL Expression |
---|
849 | ========================== |
---|
850 | |
---|
851 | RTL expressions contain several flags (one-bit bitfields) that are |
---|
852 | used in certain types of expression. Most often they are accessed with |
---|
853 | the following macros: |
---|
854 | |
---|
855 | `MEM_VOLATILE_P (X)' |
---|
856 | In `mem' expressions, nonzero for volatile memory references. |
---|
857 | Stored in the `volatil' field and printed as `/v'. |
---|
858 | |
---|
859 | `MEM_IN_STRUCT_P (X)' |
---|
860 | In `mem' expressions, nonzero for reference to an entire |
---|
861 | structure, union or array, or to a component of one. Zero for |
---|
862 | references to a scalar variable or through a pointer to a scalar. |
---|
863 | Stored in the `in_struct' field and printed as `/s'. |
---|
864 | |
---|
865 | `REG_LOOP_TEST_P' |
---|
866 | In `reg' expressions, nonzero if this register's entire life is |
---|
867 | contained in the exit test code for some loop. Stored in the |
---|
868 | `in_struct' field and printed as `/s'. |
---|
869 | |
---|
870 | `REG_USERVAR_P (X)' |
---|
871 | In a `reg', nonzero if it corresponds to a variable present in the |
---|
872 | user's source code. Zero for temporaries generated internally by |
---|
873 | the compiler. Stored in the `volatil' field and printed as `/v'. |
---|
874 | |
---|
875 | `REG_FUNCTION_VALUE_P (X)' |
---|
876 | Nonzero in a `reg' if it is the place in which this function's |
---|
877 | value is going to be returned. (This happens only in a hard |
---|
878 | register.) Stored in the `integrated' field and printed as `/i'. |
---|
879 | |
---|
880 | The same hard register may be used also for collecting the values |
---|
881 | of functions called by this one, but `REG_FUNCTION_VALUE_P' is zero |
---|
882 | in this kind of use. |
---|
883 | |
---|
884 | `SUBREG_PROMOTED_VAR_P' |
---|
885 | Nonzero in a `subreg' if it was made when accessing an object that |
---|
886 | was promoted to a wider mode in accord with the `PROMOTED_MODE' |
---|
887 | machine description macro (*note Storage Layout::.). In this |
---|
888 | case, the mode of the `subreg' is the declared mode of the object |
---|
889 | and the mode of `SUBREG_REG' is the mode of the register that |
---|
890 | holds the object. Promoted variables are always either sign- or |
---|
891 | zero-extended to the wider mode on every assignment. Stored in |
---|
892 | the `in_struct' field and printed as `/s'. |
---|
893 | |
---|
894 | `SUBREG_PROMOTED_UNSIGNED_P' |
---|
895 | Nonzero in a `subreg' that has `SUBREG_PROMOTED_VAR_P' nonzero if |
---|
896 | the object being referenced is kept zero-extended and zero if it |
---|
897 | is kept sign-extended. Stored in the `unchanging' field and |
---|
898 | printed as `/u'. |
---|
899 | |
---|
900 | `RTX_UNCHANGING_P (X)' |
---|
901 | Nonzero in a `reg' or `mem' if the value is not changed. (This |
---|
902 | flag is not set for memory references via pointers to constants. |
---|
903 | Such pointers only guarantee that the object will not be changed |
---|
904 | explicitly by the current function. The object might be changed by |
---|
905 | other functions or by aliasing.) Stored in the `unchanging' field |
---|
906 | and printed as `/u'. |
---|
907 | |
---|
908 | `RTX_INTEGRATED_P (INSN)' |
---|
909 | Nonzero in an insn if it resulted from an in-line function call. |
---|
910 | Stored in the `integrated' field and printed as `/i'. This may be |
---|
911 | deleted; nothing currently depends on it. |
---|
912 | |
---|
913 | `SYMBOL_REF_USED (X)' |
---|
914 | In a `symbol_ref', indicates that X has been used. This is |
---|
915 | normally only used to ensure that X is only declared external |
---|
916 | once. Stored in the `used' field. |
---|
917 | |
---|
918 | `SYMBOL_REF_FLAG (X)' |
---|
919 | In a `symbol_ref', this is used as a flag for machine-specific |
---|
920 | purposes. Stored in the `volatil' field and printed as `/v'. |
---|
921 | |
---|
922 | `LABEL_OUTSIDE_LOOP_P' |
---|
923 | In `label_ref' expressions, nonzero if this is a reference to a |
---|
924 | label that is outside the innermost loop containing the reference |
---|
925 | to the label. Stored in the `in_struct' field and printed as `/s'. |
---|
926 | |
---|
927 | `INSN_DELETED_P (INSN)' |
---|
928 | In an insn, nonzero if the insn has been deleted. Stored in the |
---|
929 | `volatil' field and printed as `/v'. |
---|
930 | |
---|
931 | `INSN_ANNULLED_BRANCH_P (INSN)' |
---|
932 | In an `insn' in the delay slot of a branch insn, indicates that an |
---|
933 | annulling branch should be used. See the discussion under |
---|
934 | `sequence' below. Stored in the `unchanging' field and printed as |
---|
935 | `/u'. |
---|
936 | |
---|
937 | `INSN_FROM_TARGET_P (INSN)' |
---|
938 | In an `insn' in a delay slot of a branch, indicates that the insn |
---|
939 | is from the target of the branch. If the branch insn has |
---|
940 | `INSN_ANNULLED_BRANCH_P' set, this insn should only be executed if |
---|
941 | the branch is taken. For annulled branches with this bit clear, |
---|
942 | the insn should be executed only if the branch is not taken. |
---|
943 | Stored in the `in_struct' field and printed as `/s'. |
---|
944 | |
---|
945 | `CONSTANT_POOL_ADDRESS_P (X)' |
---|
946 | Nonzero in a `symbol_ref' if it refers to part of the current |
---|
947 | function's "constants pool". These are addresses close to the |
---|
948 | beginning of the function, and GNU CC assumes they can be addressed |
---|
949 | directly (perhaps with the help of base registers). Stored in the |
---|
950 | `unchanging' field and printed as `/u'. |
---|
951 | |
---|
952 | `CONST_CALL_P (X)' |
---|
953 | In a `call_insn', indicates that the insn represents a call to a |
---|
954 | const function. Stored in the `unchanging' field and printed as |
---|
955 | `/u'. |
---|
956 | |
---|
957 | `LABEL_PRESERVE_P (X)' |
---|
958 | In a `code_label', indicates that the label can never be deleted. |
---|
959 | Labels referenced by a non-local goto will have this bit set. |
---|
960 | Stored in the `in_struct' field and printed as `/s'. |
---|
961 | |
---|
962 | `SCHED_GROUP_P (INSN)' |
---|
963 | During instruction scheduling, in an insn, indicates that the |
---|
964 | previous insn must be scheduled together with this insn. This is |
---|
965 | used to ensure that certain groups of instructions will not be |
---|
966 | split up by the instruction scheduling pass, for example, `use' |
---|
967 | insns before a `call_insn' may not be separated from the |
---|
968 | `call_insn'. Stored in the `in_struct' field and printed as `/s'. |
---|
969 | |
---|
970 | These are the fields which the above macros refer to: |
---|
971 | |
---|
972 | `used' |
---|
973 | Normally, this flag is used only momentarily, at the end of RTL |
---|
974 | generation for a function, to count the number of times an |
---|
975 | expression appears in insns. Expressions that appear more than |
---|
976 | once are copied, according to the rules for shared structure |
---|
977 | (*note Sharing::.). |
---|
978 | |
---|
979 | In a `symbol_ref', it indicates that an external declaration for |
---|
980 | the symbol has already been written. |
---|
981 | |
---|
982 | In a `reg', it is used by the leaf register renumbering code to |
---|
983 | ensure that each register is only renumbered once. |
---|
984 | |
---|
985 | `volatil' |
---|
986 | This flag is used in `mem', `symbol_ref' and `reg' expressions and |
---|
987 | in insns. In RTL dump files, it is printed as `/v'. |
---|
988 | |
---|
989 | In a `mem' expression, it is 1 if the memory reference is volatile. |
---|
990 | Volatile memory references may not be deleted, reordered or |
---|
991 | combined. |
---|
992 | |
---|
993 | In a `symbol_ref' expression, it is used for machine-specific |
---|
994 | purposes. |
---|
995 | |
---|
996 | In a `reg' expression, it is 1 if the value is a user-level |
---|
997 | variable. 0 indicates an internal compiler temporary. |
---|
998 | |
---|
999 | In an insn, 1 means the insn has been deleted. |
---|
1000 | |
---|
1001 | `in_struct' |
---|
1002 | In `mem' expressions, it is 1 if the memory datum referred to is |
---|
1003 | all or part of a structure or array; 0 if it is (or might be) a |
---|
1004 | scalar variable. A reference through a C pointer has 0 because |
---|
1005 | the pointer might point to a scalar variable. This information |
---|
1006 | allows the compiler to determine something about possible cases of |
---|
1007 | aliasing. |
---|
1008 | |
---|
1009 | In an insn in the delay slot of a branch, 1 means that this insn |
---|
1010 | is from the target of the branch. |
---|
1011 | |
---|
1012 | During instruction scheduling, in an insn, 1 means that this insn |
---|
1013 | must be scheduled as part of a group together with the previous |
---|
1014 | insn. |
---|
1015 | |
---|
1016 | In `reg' expressions, it is 1 if the register has its entire life |
---|
1017 | contained within the test expression of some loop. |
---|
1018 | |
---|
1019 | In `subreg' expressions, 1 means that the `subreg' is accessing an |
---|
1020 | object that has had its mode promoted from a wider mode. |
---|
1021 | |
---|
1022 | In `label_ref' expressions, 1 means that the referenced label is |
---|
1023 | outside the innermost loop containing the insn in which the |
---|
1024 | `label_ref' was found. |
---|
1025 | |
---|
1026 | In `code_label' expressions, it is 1 if the label may never be |
---|
1027 | deleted. This is used for labels which are the target of |
---|
1028 | non-local gotos. |
---|
1029 | |
---|
1030 | In an RTL dump, this flag is represented as `/s'. |
---|
1031 | |
---|
1032 | `unchanging' |
---|
1033 | In `reg' and `mem' expressions, 1 means that the value of the |
---|
1034 | expression never changes. |
---|
1035 | |
---|
1036 | In `subreg' expressions, it is 1 if the `subreg' references an |
---|
1037 | unsigned object whose mode has been promoted to a wider mode. |
---|
1038 | |
---|
1039 | In an insn, 1 means that this is an annulling branch. |
---|
1040 | |
---|
1041 | In a `symbol_ref' expression, 1 means that this symbol addresses |
---|
1042 | something in the per-function constants pool. |
---|
1043 | |
---|
1044 | In a `call_insn', 1 means that this instruction is a call to a |
---|
1045 | const function. |
---|
1046 | |
---|
1047 | In an RTL dump, this flag is represented as `/u'. |
---|
1048 | |
---|
1049 | `integrated' |
---|
1050 | In some kinds of expressions, including insns, this flag means the |
---|
1051 | rtl was produced by procedure integration. |
---|
1052 | |
---|
1053 | In a `reg' expression, this flag indicates the register containing |
---|
1054 | the value to be returned by the current function. On machines |
---|
1055 | that pass parameters in registers, the same register number may be |
---|
1056 | used for parameters as well, but this flag is not set on such uses. |
---|
1057 | |
---|