![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-8 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 1.x] / gcc|
Return to gcc.info-8 CVS log | Up to [GCC 1.x] / gcc |
1.1 root 1: Info file gcc.info, produced by Makeinfo, -*- Text -*- from input
2: file gcc.texinfo.
3:
4: This file documents the use and the internals of the GNU compiler.
5:
1.1.1.4 ! root 6: Copyright (C) 1988, 1989, 1990 Free Software Foundation, Inc.
1.1 root 7:
8: Permission is granted to make and distribute verbatim copies of this
9: manual provided the copyright notice and this permission notice are
10: preserved on all copies.
11:
12: Permission is granted to copy and distribute modified versions of
13: this manual under the conditions for verbatim copying, provided also
1.1.1.4 ! root 14: that the sections entitled "GNU General Public License" and "Protect
! 15: Your Freedom--Fight `Look And Feel'" are included exactly as in the
! 16: original, and provided that the entire resulting derived work is
! 17: distributed under the terms of a permission notice identical to this
! 18: one.
1.1 root 19:
20: Permission is granted to copy and distribute translations of this
21: manual into another language, under the above conditions for modified
1.1.1.4 ! root 22: versions, except that the sections entitled "GNU General Public
! 23: License" and "Protect Your Freedom--Fight `Look And Feel'" and this
! 24: permission notice may be included in translations approved by the
! 25: Free Software Foundation instead of in the original English.
1.1 root 26:
27:
28:
1.1.1.3 root 29: File: gcc.info, Node: Peephole Definitions, Next: Expander Definitions, Prev: Jump Patterns, Up: Machine Desc
1.1.1.2 root 30:
1.1.1.3 root 31: Defining Machine-Specific Peephole Optimizers
32: =============================================
1.1.1.2 root 33:
1.1.1.3 root 34: In addition to instruction patterns the `md' file may contain
35: definitions of machine-specific peephole optimizations.
1.1.1.2 root 36:
1.1.1.3 root 37: The combiner does not notice certain peephole optimizations when the
38: data flow in the program does not suggest that it should try them.
39: For example, sometimes two consecutive insns related in purpose can
40: be combined even though the second one does not appear to use a
41: register computed in the first one. A machine-specific peephole
42: optimizer can detect such opportunities.
43:
44: A definition looks like this:
45:
46: (define_peephole
47: [INSN-PATTERN-1
48: INSN-PATTERN-2
49: ...]
50: "CONDITION"
51: "TEMPLATE"
52: "MACHINE-SPECIFIC INFO")
53:
54: The last string operand may be omitted if you are not using any
55: machine-specific information in this machine description. If
56: present, it must obey the same rules as in a `define_insn'.
57:
58: In this skeleton, INSN-PATTERN-1 and so on are patterns to match
59: consecutive insns. The optimization applies to a sequence of insns
60: when INSN-PATTERN-1 matches the first one, INSN-PATTERN-2 matches the
61: next, and so on.
62:
63: Each of the insns matched by a peephole must also match a
64: `define_insn'. Peepholes are checked only at the last stage just
65: before code generation, and only optionally. Therefore, any insn
66: which would match a peephole but no `define_insn' will cause a crash
67: in code generation in an unoptimized compilation, or at various
68: optimization stages.
69:
70: The operands of the insns are matched with `match_operands' and
71: `match_dup', as usual. What is not usual is that the operand numbers
72: apply to all the insn patterns in the definition. So, you can check
73: for identical operands in two insns by using `match_operand' in one
74: insn and `match_dup' in the other.
75:
76: The operand constraints used in `match_operand' patterns do not have
77: any direct effect on the applicability of the peephole, but they will
78: be validated afterward, so make sure your constraints are general
79: enough to apply whenever the peephole matches. If the peephole
80: matches but the constraints are not satisfied, the compiler will crash.
81:
82: It is safe to omit constraints in all the operands of the peephole;
83: or you can write constraints which serve as a double-check on the
84: criteria previously tested.
85:
86: Once a sequence of insns matches the patterns, the CONDITION is
87: checked. This is a C expression which makes the final decision
88: whether to perform the optimization (we do so if the expression is
89: nonzero). If CONDITION is omitted (in other words, the string is
90: empty) then the optimization is applied to every sequence of insns
91: that matches the patterns.
92:
93: The defined peephole optimizations are applied after register
94: allocation is complete. Therefore, the peephole definition can check
95: which operands have ended up in which kinds of registers, just by
96: looking at the operands.
97:
98: The way to refer to the operands in CONDITION is to write
99: `operands[I]' for operand number I (as matched by `(match_operand I
100: ...)'). Use the variable `insn' to refer to the last of the insns
101: being matched; use `PREV_INSN' to find the preceding insns (but be
102: careful to skip over any `note' insns that intervene).
103:
104: When optimizing computations with intermediate results, you can use
105: CONDITION to match only when the intermediate results are not used
106: elsewhere. Use the C expression `dead_or_set_p (INSN, OP)', where
107: INSN is the insn in which you expect the value to be used for the
108: last time (from the value of `insn', together with use of
109: `PREV_INSN'), and OP is the intermediate value (from `operands[I]').
110:
111: Applying the optimization means replacing the sequence of insns with
112: one new insn. The TEMPLATE controls ultimate output of assembler
113: code for this combined insn. It works exactly like the template of a
114: `define_insn'. Operand numbers in this template are the same ones
115: used in matching the original sequence of insns.
116:
117: The result of a defined peephole optimizer does not need to match any
118: of the insn patterns in the machine description; it does not even
119: have an opportunity to match them. The peephole optimizer definition
120: itself serves as the insn pattern to control how the insn is output.
121:
122: Defined peephole optimizers are run as assembler code is being
123: output, so the insns they produce are never combined or rearranged in
124: any way.
125:
126: Here is an example, taken from the 68000 machine description:
127:
128: (define_peephole
129: [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4)))
130: (set (match_operand:DF 0 "register_operand" "f")
131: (match_operand:DF 1 "register_operand" "ad"))]
132: "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])"
133: "*
134: {
135: rtx xoperands[2];
136: xoperands[1] = gen_rtx (REG, SImode, REGNO (operands[1]) + 1);
137: #ifdef MOTOROLA
138: output_asm_insn (\"move.l %1,(sp)\", xoperands);
139: output_asm_insn (\"move.l %1,-(sp)\", operands);
140: return \"fmove.d (sp)+,%0\";
141: #else
142: output_asm_insn (\"movel %1,sp@\", xoperands);
143: output_asm_insn (\"movel %1,sp@-\", operands);
144: return \"fmoved sp@+,%0\";
145: #endif
146: }
147: ")
148:
149: The effect of this optimization is to change
150:
151: jbsr _foobar
152: addql #4,sp
153: movel d1,sp@-
154: movel d0,sp@-
155: fmoved sp@+,fp0
156:
157: into
158:
159: jbsr _foobar
160: movel d1,sp@
161: movel d0,sp@-
162: fmoved sp@+,fp0
163:
164: INSN-PATTERN-1 and so on look *almost* like the second operand of
165: `define_insn'. There is one important difference: the second operand
166: of `define_insn' consists of one or more RTX's enclosed in square
167: brackets. Usually, there is only one: then the same action can be
168: written as an element of a `define_peephole'. But when there are
169: multiple actions in a `define_insn', they are implicitly enclosed in
170: a `parallel'. Then you must explicitly write the `parallel', and the
171: square brackets within it, in the `define_peephole'. Thus, if an
172: insn pattern looks like this,
173:
174: (define_insn "divmodsi4"
175: [(set (match_operand:SI 0 "general_operand" "=d")
176: (div:SI (match_operand:SI 1 "general_operand" "0")
177: (match_operand:SI 2 "general_operand" "dmsK")))
178: (set (match_operand:SI 3 "general_operand" "=d")
179: (mod:SI (match_dup 1) (match_dup 2)))]
180: "TARGET_68020"
181: "divsl%.l %2,%3:%0")
182:
183: then the way to mention this insn in a peephole is as follows:
184:
185: (define_peephole
186: [...
187: (parallel
188: [(set (match_operand:SI 0 "general_operand" "=d")
189: (div:SI (match_operand:SI 1 "general_operand" "0")
190: (match_operand:SI 2 "general_operand" "dmsK")))
191: (set (match_operand:SI 3 "general_operand" "=d")
192: (mod:SI (match_dup 1) (match_dup 2)))])
193: ...]
194: ...)
1.1.1.2 root 195:
196:
197:
1.1.1.3 root 198: File: gcc.info, Node: Expander Definitions, Prev: Peephole Definitions, Up: Machine Desc
1.1.1.2 root 199:
1.1.1.3 root 200: Defining RTL Sequences for Code Generation
201: ==========================================
1.1.1.2 root 202:
1.1.1.3 root 203: On some target machines, some standard pattern names for RTL
204: generation cannot be handled with single insn, but a sequence of RTL
205: insns can represent them. For these target machines, you can write a
206: `define_expand' to specify how to generate the sequence of RTL.
207:
208: A `define_expand' is an RTL expression that looks almost like a
209: `define_insn'; but, unlike the latter, a `define_expand' is used only
210: for RTL generation and it can produce more than one RTL insn.
211:
212: A `define_expand' RTX has four operands:
213:
214: * The name. Each `define_expand' must have a name, since the only
215: use for it is to refer to it by name.
216:
217: * The RTL template. This is just like the RTL template for a
218: `define_peephole' in that it is a vector of RTL expressions each
219: being one insn.
220:
221: * The condition, a string containing a C expression. This
222: expression is used to express how the availability of this
223: pattern depends on subclasses of target machine, selected by
224: command-line options when GNU CC is run. This is just like the
225: condition of a `define_insn' that has a standard name.
226:
227: * The preparation statements, a string containing zero or more C
228: statements which are to be executed before RTL code is generated
229: from the RTL template.
230:
231: Usually these statements prepare temporary registers for use as
232: internal operands in the RTL template, but they can also
233: generate RTL insns directly by calling routines such as
234: `emit_insn', etc. Any such insns precede the ones that come
235: from the RTL template.
236:
237: Every RTL insn emitted by a `define_expand' must match some
238: `define_insn' in the machine description. Otherwise, the compiler
239: will crash when trying to generate code for the insn or trying to
240: optimize it.
241:
242: The RTL template, in addition to controlling generation of RTL insns,
243: also describes the operands that need to be specified when this
244: pattern is used. In particular, it gives a predicate for each operand.
245:
246: A true operand, which need to be specified in order to generate RTL
247: from the pattern, should be described with a `match_operand' in its
248: first occurrence in the RTL template. This enters information on the
249: operand's predicate into the tables that record such things. GNU CC
250: uses the information to preload the operand into a register if that
251: is required for valid RTL code. If the operand is referred to more
252: than once, subsequent references should use `match_dup'.
253:
1.1.1.4 ! root 254: The RTL template may also refer to internal "operands" which are
1.1.1.3 root 255: temporary registers or labels used only within the sequence made by
256: the `define_expand'. Internal operands are substituted into the RTL
257: template with `match_dup', never with `match_operand'. The values of
258: the internal operands are not passed in as arguments by the compiler
259: when it requests use of this pattern. Instead, they are computed
260: within the pattern, in the preparation statements. These statements
261: compute the values and store them into the appropriate elements of
262: `operands' so that `match_dup' can find them.
263:
264: There are two special macros defined for use in the preparation
265: statements: `DONE' and `FAIL'. Use them with a following semicolon,
266: as a statement.
267:
268: `DONE'
269: Use the `DONE' macro to end RTL generation for the pattern. The
270: only RTL insns resulting from the pattern on this occasion will
271: be those already emitted by explicit calls to `emit_insn' within
272: the preparation statements; the RTL template will not be
273: generated.
274:
275: `FAIL'
276: Make the pattern fail on this occasion. When a pattern fails,
277: it means that the pattern was not truly available. The calling
278: routines in the compiler will try other strategies for code
279: generation using other patterns.
280:
281: Failure is currently supported only for binary operations
282: (addition, multiplication, shifting, etc.).
283:
284: Do not emit any insns explicitly with `emit_insn' before failing.
285:
286: Here is an example, the definition of left-shift for the SPUR chip:
287:
288: (define_expand "ashlsi3"
289: [(set (match_operand:SI 0 "register_operand" "")
290: (ashift:SI
291: (match_operand:SI 1 "register_operand" "")
292: (match_operand:SI 2 "nonmemory_operand" "")))]
293: ""
294: "
295: {
296: if (GET_CODE (operands[2]) != CONST_INT
297: || (unsigned) INTVAL (operands[2]) > 3)
298: FAIL;
299: }")
300:
301: This example uses `define_expand' so that it can generate an RTL insn
302: for shifting when the shift-count is in the supported range of 0 to 3
303: but fail in other cases where machine insns aren't available. When
304: it fails, the compiler tries another strategy using different
305: patterns (such as, a library call).
306:
307: If the compiler were able to handle nontrivial condition-strings in
308: patterns with names, then it would be possible to use a `define_insn'
309: in that case. Here is another case (zero-extension on the 68000)
310: which makes more use of the power of `define_expand':
311:
312: (define_expand "zero_extendhisi2"
313: [(set (match_operand:SI 0 "general_operand" "")
314: (const_int 0))
315: (set (strict_low_part
316: (subreg:HI
317: (match_dup 0)
318: 0))
319: (match_operand:HI 1 "general_operand" ""))]
320: ""
321: "operands[1] = make_safe_from (operands[1], operands[0]);")
322:
323: Here two RTL insns are generated, one to clear the entire output
324: operand and the other to copy the input operand into its low half.
325: This sequence is incorrect if the input operand refers to [the old
326: value of] the output operand, so the preparation statement makes sure
327: this isn't so. The function `make_safe_from' copies the
328: `operands[1]' into a temporary register if it refers to
329: `operands[0]'. It does this by emitting another RTL insn.
330:
331: Finally, a third example shows the use of an internal operand.
332: Zero-extension on the SPUR chip is done by `and'-ing the result
333: against a halfword mask. But this mask cannot be represented by a
334: `const_int' because the constant value is too large to be legitimate
335: on this machine. So it must be copied into a register with
336: `force_reg' and then the register used in the `and'.
337:
338: (define_expand "zero_extendhisi2"
339: [(set (match_operand:SI 0 "register_operand" "")
340: (and:SI (subreg:SI
341: (match_operand:HI 1 "register_operand" "")
342: 0)
343: (match_dup 2)))]
344: ""
345: "operands[2]
346: = force_reg (SImode, gen_rtx (CONST_INT,
347: VOIDmode, 65535)); ")
348:
349: *Note:* If the `define_expand' is used to serve a standard binary or
350: unary arithmetic operation, then the last insn it generates must not
351: be a `code_label', `barrier' or `note'. It must be an `insn',
352: `jump_insn' or `call_insn'.
1.1.1.2 root 353:
354:
355:
1.1.1.3 root 356: File: gcc.info, Node: Machine Macros, Next: Config, Prev: Machine Desc, Up: Top
1.1.1.2 root 357:
1.1.1.3 root 358: Machine Description Macros
359: **************************
1.1.1.2 root 360:
1.1.1.3 root 361: The other half of the machine description is a C header file
362: conventionally given the name `tm-MACHINE.h'. The file `tm.h' should
363: be a link to it. The header file `config.h' includes `tm.h' and most
364: compiler source files include `config.h'.
365:
366: * Menu:
367:
368: * Run-time Target:: Defining `-m' options like `-m68000' and `-m68020'.
369: * Storage Layout:: Defining sizes and alignments of data types.
370: * Registers:: Naming and describing the hardware registers.
371: * Register Classes:: Defining the classes of hardware registers.
372: * Stack Layout:: Defining which way the stack grows and by how much.
373: * Library Names:: Specifying names of subroutines to call automatically.
374: * Addressing Modes:: Defining addressing modes valid for memory operands.
375: * Delayed Branch:: Do branches execute the following instruction?
376: * Condition Code:: Defining how insns update the condition code.
377: * Assembler Format:: Defining how to write insns and pseudo-ops to output.
378: * Cross-compilation:: Handling floating point for cross-compilers.
379: * Misc:: Everything else.
1.1.1.2 root 380:
1.1.1.3 root 381:
1.1.1.2 root 382:
1.1.1.3 root 383: File: gcc.info, Node: Run-time Target, Next: Storage Layout, Prev: Machine Macros, Up: Machine Macros
1.1.1.2 root 384:
1.1.1.3 root 385: Run-time Target Specification
386: =============================
1.1.1.2 root 387:
1.1.1.3 root 388: `CPP_PREDEFINES'
389: Define this to be a string constant containing `-D' options to
390: define the predefined macros that identify this machine and
391: system. These macros will be predefined unless the `-ansi'
392: option is specified.
1.1.1.2 root 393:
1.1.1.3 root 394: In addition, a parallel set of macros are predefined, whose
395: names are made by appending `__' at the beginning and at the
396: end. These `__' macros are permitted by the ANSI standard, so
397: they are predefined regardless of whether `-ansi' is specified.
1.1.1.2 root 398:
1.1.1.3 root 399: For example, on the Sun, one can use the following value:
400:
401: "-Dmc68000 -Dsun -Dunix"
1.1 root 402:
1.1.1.3 root 403: The result is to define the macros `__mc68000__', `__sun__' and
404: `__unix__' unconditionally, and the macros `mc68000', `sun' and
405: `unix' provided `-ansi' is not specified.
1.1 root 406:
1.1.1.3 root 407: `CPP_SPEC'
1.1 root 408: A C string constant that tells the GNU CC driver program options
1.1.1.3 root 409: to pass to CPP. It can also specify how to translate options
410: you give to GNU CC into options for GNU CC to pass to the CPP.
1.1 root 411:
412: Do not define this macro if it does not need to do anything.
413:
1.1.1.3 root 414: `CC1_SPEC'
1.1 root 415: A C string constant that tells the GNU CC driver program options
1.1.1.3 root 416: to pass to CC1. It can also specify how to translate options
417: you give to GNU CC into options for GNU CC to pass to the CC1.
1.1 root 418:
419: Do not define this macro if it does not need to do anything.
420:
1.1.1.3 root 421: `extern int target_flags;'
422: This declaration should be present.
1.1 root 423:
1.1.1.3 root 424: `TARGET_...'
425: This series of macros is to allow compiler command arguments to
426: enable or disable the use of optional features of the target
427: machine. For example, one machine description serves both the
428: 68000 and the 68020; a command argument tells the compiler
429: whether it should use 68020-only instructions or not. This
430: command argument works by means of a macro `TARGET_68020' that
431: tests a bit in `target_flags'.
432:
433: Define a macro `TARGET_FEATURENAME' for each such option. Its
434: definition should test a bit in `target_flags'; for example:
435:
436: #define TARGET_68020 (target_flags & 1)
437:
438: One place where these macros are used is in the
439: condition-expressions of instruction patterns. Note how
440: `TARGET_68020' appears frequently in the 68000 machine
441: description file, `m68k.md'. Another place they are used is in
442: the definitions of the other macros in the `tm-MACHINE.h' file.
443:
444: `TARGET_SWITCHES'
445: This macro defines names of command options to set and clear
446: bits in `target_flags'. Its definition is an initializer with a
447: subgrouping for each command option.
448:
449: Each subgrouping contains a string constant, that defines the
450: option name, and a number, which contains the bits to set in
451: `target_flags'. A negative number says to clear bits instead;
452: the negative of the number is which bits to clear. The actual
453: option name is made by appending `-m' to the specified name.
454:
455: One of the subgroupings should have a null string. The number
456: in this grouping is the default value for `target_flags'. Any
457: target options act starting with that value.
458:
459: Here is an example which defines `-m68000' and `-m68020' with
460: opposite meanings, and picks the latter as the default:
461:
462: #define TARGET_SWITCHES \
463: { { "68020", 1}, \
464: { "68000", -1}, \
465: { "", 1}}
466:
467: `OVERRIDE_OPTIONS'
468: Sometimes certain combinations of command options do not make
469: sense on a particular target machine. You can define a macro
470: `OVERRIDE_OPTIONS' to take account of this. This macro, if
471: defined, is executed once just after all the command options
472: have been parsed.
1.1 root 473:
474:
475:
1.1.1.3 root 476: File: gcc.info, Node: Storage Layout, Next: Registers, Prev: Run-time Target, Up: Machine Macros
477:
478: Storage Layout
479: ==============
480:
481: Note that the definitions of the macros in this table which are sizes
482: or alignments measured in bits do not need to be constant. They can
483: be C expressions that refer to static variables, such as the
484: `target_flags'. *Note Run-time Target::.
485:
486: `BITS_BIG_ENDIAN'
487: Define this macro if the most significant bit in a byte has the
488: lowest number. This means that bit-field instructions count
489: from the most significant bit. If the machine has no bit-field
490: instructions, this macro is irrelevant.
491:
492: This macro does not affect the way structure fields are packed
493: into bytes or words; that is controlled by `BYTES_BIG_ENDIAN'.
494:
495: `BYTES_BIG_ENDIAN'
496: Define this macro if the most significant byte in a word has the
497: lowest number.
498:
499: `WORDS_BIG_ENDIAN'
500: Define this macro if, in a multiword object, the most
501: significant word has the lowest number.
502:
503: `BITS_PER_UNIT'
504: Number of bits in an addressable storage unit (byte); normally 8.
505:
506: `BITS_PER_WORD'
507: Number of bits in a word; normally 32.
508:
509: `UNITS_PER_WORD'
510: Number of storage units in a word; normally 4.
511:
512: `POINTER_SIZE'
513: Width of a pointer, in bits.
514:
515: `POINTER_BOUNDARY'
516: Alignment required for pointers stored in memory, in bits.
517:
518: `PARM_BOUNDARY'
519: Normal alignment required for function parameters on the stack,
520: in bits. All stack parameters receive least this much alignment
521: regardless of data type. On most machines, this is the same as
522: the size of an integer.
523:
524: `MAX_PARM_BOUNDARY'
525: Largest alignment required for any stack parameters, in bits.
526: If the data type of the parameter calls for more alignment than
527: `PARM_BOUNDARY', then it is given extra padding up to this limit.
528:
529: Don't define this macro if it would be equal to `PARM_BOUNDARY';
530: in other words, if the alignment of a stack parameter should not
531: depend on its data type (as is the case on most machines).
532:
533: `STACK_BOUNDARY'
534: Define this macro if you wish to preserve a certain alignment
535: for the stack pointer at all times. The definition is a C
536: expression for the desired alignment (measured in bits).
537:
538: `FUNCTION_BOUNDARY'
539: Alignment required for a function entry point, in bits.
540:
541: `BIGGEST_ALIGNMENT'
542: Biggest alignment that any data type can require on this
543: machine, in bits.
544:
545: `CONSTANT_ALIGNMENT (CODE, TYPEALIGN)'
546: A C expression to compute the alignment for a constant. The
547: argument TYPEALIGN is the alignment required for the constant's
548: data type. CODE is the tree code of the constant itself.
549:
550: If this macro is not defined, the default is to use TYPEALIGN.
551: If you do define this macro, the value must be a multiple of
552: TYPEALIGN.
553:
554: The purpose of defining this macro is usually to cause string
555: constants to be word aligned so that `dhrystone' can be made to
556: run faster.
557:
558: `EMPTY_FIELD_BOUNDARY'
559: Alignment in bits to be given to a structure bit field that
560: follows an empty field such as `int : 0;'.
561:
562: `STRUCTURE_SIZE_BOUNDARY'
563: Number of bits which any structure or union's size must be a
564: multiple of. Each structure or union's size is rounded up to a
565: multiple of this.
566:
567: If you do not define this macro, the default is the same as
568: `BITS_PER_UNIT'.
569:
570: `STRICT_ALIGNMENT'
571: Define this if instructions will fail to work if given data not
572: on the nominal alignment. If instructions will merely go slower
573: in that case, do not define this macro.
574:
575: `PCC_BITFIELD_TYPE_MATTERS'
576: Define this if you wish to imitate a certain bizarre behavior
577: pattern of some instances of PCC: a bit field whose declared
578: type is `int' has the same effect on the size and alignment of a
579: structure as an actual `int' would have.
580:
1.1.1.4 ! root 581: If the macro is defined, then its definition should be a C
! 582: expression; a nonzero value for the expression enables
! 583: PCC-compatible behavior.
! 584:
1.1.1.3 root 585: Just what effect that is in GNU CC depends on other parameters,
586: but on most machines it would force the structure's alignment
587: and size to a multiple of 32 or `BIGGEST_ALIGNMENT' bits.
588:
589: `MAX_FIXED_MODE_SIZE'
590: An integer expression for the largest integer machine mode that
591: should actually be used. All integer machine modes of this size
592: or smaller can be used for structures and unions with the
593: appropriate sizes.
594:
595: `CHECK_FLOAT_VALUE (MODE, VALUE)'
596: A C statement to validate the value VALUE (or type `double') for
597: mode MODE. This means that you check whether VALUE fits within
598: the possible range of values for mode MODE on this target
599: machine. The mode MODE is always `SFmode' or `DFmode'.
600:
601: If VALUE is not valid, you should call `error' to print an error
602: message and then assign some valid value to VALUE. Allowing an
603: invalid value to go through the compiler can produce incorrect
604: assembler code which may even cause Unix assemblers to crash.
605:
606: This macro need not be defined if there is no work for it to do.
607:
608:
609:
610: File: gcc.info, Node: Registers, Next: Register Classes, Prev: Storage Layout, Up: Machine Macros
611:
612: Register Usage
613: ==============
614:
615: `FIRST_PSEUDO_REGISTER'
616: Number of hardware registers known to the compiler. They
617: receive numbers 0 through `FIRST_PSEUDO_REGISTER-1'; thus, the
618: first pseudo register's number really is assigned the number
619: `FIRST_PSEUDO_REGISTER'.
620:
621: `FIXED_REGISTERS'
622: An initializer that says which registers are used for fixed
623: purposes all throughout the compiled code and are therefore not
624: available for general allocation. These would include the stack
625: pointer, the frame pointer (except on machines where that can be
626: used as a general register when no frame pointer is needed), the
627: program counter on machines where that is considered one of the
628: addressable registers, and any other numbered register with a
629: standard use.
630:
631: This information is expressed as a sequence of numbers,
632: separated by commas and surrounded by braces. The Nth number is
633: 1 if register N is fixed, 0 otherwise.
634:
635: The table initialized from this macro, and the table initialized
636: by the following one, may be overridden at run time either
637: automatically, by the actions of the macro
638: `CONDITIONAL_REGISTER_USAGE', or by the user with the command
639: options `-ffixed-REG', `-fcall-used-REG' and `-fcall-saved-REG'.
640:
641: `CALL_USED_REGISTERS'
642: Like `FIXED_REGISTERS' but has 1 for each register that is
643: clobbered (in general) by function calls as well as for fixed
644: registers. This macro therefore identifies the registers that
645: are not available for general allocation of values that must
646: live across function calls.
647:
648: If a register has 0 in `CALL_USED_REGISTERS', the compiler
649: automatically saves it on function entry and restores it on
650: function exit, if the register is used within the function.
651:
652: `DEFAULT_CALLER_SAVES'
653: Define this macro if function calls on the target machine do not
654: preserve any registers; in other words, if `CALL_USED_REGISTERS'
655: has 1 for all registers. This macro enables `-fcaller-saves' by
656: default. Eventually that option will be enabled by default on
657: all machines and both the option and this macro will be
658: eliminated.
659:
660: `CONDITIONAL_REGISTER_USAGE'
661: Zero or more C statements that may conditionally modify two
662: variables `fixed_regs' and `call_used_regs' (both of type `char
663: []') after they have been initialized from the two preceding
664: macros.
665:
666: This is necessary in case the fixed or call-clobbered registers
667: depend on target flags.
668:
669: You need not define this macro if it has no work to do.
670:
671: If the usage of an entire class of registers depends on the
672: target flags, you may indicate this to GCC by using this macro
673: to modify `fixed_regs' and `call_used_regs' to 1 for each of the
674: registers in the classes which should not be used by GCC. Also
675: define the macro `REG_CLASS_FROM_LETTER' to return `NO_REGS' if
676: it is called with a letter for a class that shouldn't be used.
677:
678: (However, if this class is not included in `GENERAL_REGS' and
679: all of the insn patterns whose constraints permit this class are
680: controlled by target switches, then GCC will automatically avoid
681: using these registers when the target switches are opposed to
682: them.)
683:
684: `OVERLAPPING_REGNO_P (REGNO)'
685: If defined, this is a C expression whose value is nonzero if
686: hard register number REGNO is an overlapping register. This
687: means a hard register which overlaps a hard register with a
688: different number. (Such overlap is undesirable, but
689: occasionally it allows a machine to be supported which otherwise
690: could not be.) This macro must return nonzero for *all* the
691: registers which overlap each other. GNU CC can use an
692: overlapping register only in certain limited ways. It can be
693: used for allocation within a basic block, and may be spilled for
694: reloading; that is all.
695:
696: If this macro is not defined, it means that none of the hard
697: registers overlap each other. This is the usual situation.
698:
699: `INSN_CLOBBERS_REGNO_P (INSN, REGNO)'
700: If defined, this is a C expression whose value should be nonzero
701: if the insn INSN has the effect of mysteriously clobbering the
1.1.1.4 ! root 702: contents of hard register number REGNO. By "mysterious" we mean
! 703: that the insn's RTL expression doesn't describe such an effect.
1.1.1.3 root 704:
705: If this macro is not defined, it means that no insn clobbers
706: registers mysteriously. This is the usual situation; all else
707: being equal, it is best for the RTL expression to show all the
708: activity.
709:
710: `PRESERVE_DEATH_INFO_REGNO_P (REGNO)'
711: If defined, this is a C expression whose value is nonzero if
712: accurate `REG_DEAD' notes are needed for hard register number
713: REGNO at the time of outputting the assembler code. When this
714: is so, a few optimizations that take place after register
715: allocation and could invalidate the death notes are not done
716: when this register is involved.
717:
718: You would arrange to preserve death info for a register when
719: some of the code in the machine description which is executed to
720: write the assembler code looks at the death notes. This is
721: necessary only when the actual hardware feature which GNU CC
722: thinks of as a register is not actually a register of the usual
723: sort. (It might, for example, be a hardware stack.)
724:
725: If this macro is not defined, it means that no death notes need
726: to be preserved. This is the usual situation.
727:
1.1.1.4 ! root 728: `HARD_REGNO_NREGS (REGNO, MODE)'
1.1.1.3 root 729: A C expression for the number of consecutive hard registers,
730: starting at register number REGNO, required to hold a value of
731: mode MODE.
732:
733: On a machine where all registers are exactly one word, a
734: suitable definition of this macro is
735:
736: #define HARD_REGNO_NREGS(REGNO, MODE) \
737: ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \
738: / UNITS_PER_WORD))
739:
740: `HARD_REGNO_MODE_OK (REGNO, MODE)'
741: A C expression that is nonzero if it is permissible to store a
742: value of mode MODE in hard register number REGNO (or in several
743: registers starting with that one). For a machine where all
744: registers are equivalent, a suitable definition is
745:
746: #define HARD_REGNO_MODE_OK(REGNO, MODE) 1
747:
748: It is not necessary for this macro to check for the numbers of
749: fixed registers, because the allocation mechanism considers them
750: to be always occupied.
751:
752: On some machines, double-precision values must be kept in
753: even/odd register pairs. The way to implement that is to define
754: this macro to reject odd register numbers for such modes.
755:
756: GNU CC assumes that it can always move values between registers
757: and (suitably addressed) memory locations. If it is impossible
758: to move a value of a certain mode between memory and certain
759: registers, then `HARD_REGNO_MODE_OK' must not allow this mode in
760: those registers.
761:
762: Many machines have special registers for floating point
763: arithmetic. Often people assume that floating point machine
764: modes are allowed only in floating point registers. This is not
765: true. Any registers that can hold integers can safely *hold* a
766: floating point machine mode, whether or not floating arithmetic
767: can be done on it in those registers.
768:
769: On some machines, though, the converse is true: fixed-point
770: machine modes may not go in floating registers. This is true if
771: the floating registers normalize any value stored in them,
772: because storing a non-floating value there would garble it. In
773: this case, `HARD_REGNO_MODE_OK' should reject fixed-point
774: machine modes in floating registers. But if the floating
775: registers do not automatically normalize, if you can store any
776: bit pattern in one and retrieve it unchanged without a trap,
777: then any machine mode may go in a floating register and this
778: macro should say so.
779:
780: The primary significance of special floating registers is rather
781: that they are the registers acceptable in floating point
782: arithmetic instructions. However, this is of no concern to
783: `HARD_REGNO_MODE_OK'. You handle it by writing the proper
784: constraints for those instructions.
785:
786: On some machines, the floating registers are especially slow to
787: access, so that it is better to store a value in a stack frame
788: than in such a register if floating point arithmetic is not
789: being done. As long as the floating registers are not in class
790: `GENERAL_REGS', they will not be used unless some insn's
791: constraint asks for one.
792:
793: `MODES_TIEABLE_P (MODE1, MODE2)'
794: A C expression that is nonzero if it is desirable to choose
795: register allocation so as to avoid move instructions between a
796: value of mode MODE1 and a value of mode MODE2.
797:
798: If `HARD_REGNO_MODE_OK (R, MODE1)' and `HARD_REGNO_MODE_OK (R,
799: MODE2)' are ever different for any R, then `MODES_TIEABLE_P
800: (MODE1, MODE2)' must be zero.
801:
802: `PC_REGNUM'
803: If the program counter has a register number, define this as
804: that register number. Otherwise, do not define it.
805:
806: `STACK_POINTER_REGNUM'
807: The register number of the stack pointer register, which must
808: also be a fixed register according to `FIXED_REGISTERS'. On
809: many machines, the hardware determines which register this is.
810:
811: `FRAME_POINTER_REGNUM'
812: The register number of the frame pointer register, which is used
813: to access automatic variables in the stack frame. On some
814: machines, the hardware determines which register this is. On
815: other machines, you can choose any register you wish for this
816: purpose.
817:
818: `FRAME_POINTER_REQUIRED'
819: A C expression which is nonzero if a function must have and use
820: a frame pointer. This expression is evaluated twice: at the
821: beginning of generating RTL, and in the reload pass. If its
822: value is nonzero at either time, then the function will have a
823: frame pointer.
824:
825: The expression can in principle examine the current function and
826: decide according to the facts, but on most machines the constant
827: 0 or the constant 1 suffices. Use 0 when the machine allows
828: code to be generated with no frame pointer, and doing so saves
829: some time or space. Use 1 when there is no possible advantage
830: to avoiding a frame pointer.
831:
832: In certain cases, the compiler does not know how to produce
833: valid code without a frame pointer. The compiler recognizes
834: those cases and automatically gives the function a frame pointer
835: regardless of what `FRAME_POINTER_REQUIRED' says. You don't
836: need to worry about them.
837:
838: In a function that does not require a frame pointer, the frame
839: pointer register can be allocated for ordinary usage, unless you
840: mark it as a fixed register. See `FIXED_REGISTERS' for more
841: information.
842:
843: `ARG_POINTER_REGNUM'
844: The register number of the arg pointer register, which is used
845: to access the function's argument list. On some machines, this
846: is the same as the frame pointer register. On some machines,
847: the hardware determines which register this is. On other
848: machines, you can choose any register you wish for this purpose.
849: If this is not the same register as the frame pointer register,
850: then you must mark it as a fixed register according to
851: `FIXED_REGISTERS'.
852:
853: `STATIC_CHAIN_REGNUM'
854: The register number used for passing a function's static chain
855: pointer. This is needed for languages such as Pascal and Algol
856: where functions defined within other functions can access the
857: local variables of the outer functions; it is not currently used
858: because C does not provide this feature, but you must define the
859: macro.
860:
861: The static chain register need not be a fixed register.
862:
863: `STRUCT_VALUE_REGNUM'
864: When a function's value's mode is `BLKmode', the value is not
865: returned according to `FUNCTION_VALUE'. Instead, the caller
866: passes the address of a block of memory in which the value
867: should be stored.
868:
869: If this value is passed in a register, then
870: `STRUCT_VALUE_REGNUM' should be the number of that register.
871:
872: `STRUCT_VALUE'
873: If the structure value address is not passed in a register,
874: define `STRUCT_VALUE' as an expression returning an RTX for the
875: place where the address is passed. If it returns a `mem' RTX,
1.1.1.4 ! root 876: the address is passed as an "invisible" first argument.
1.1.1.3 root 877:
878: `STRUCT_VALUE_INCOMING_REGNUM'
879: On some architectures the place where the structure value
880: address is found by the called function is not the same place
881: that the caller put it. This can be due to register windows, or
882: it could be because the function prologue moves it to a
883: different place.
884:
885: If the incoming location of the structure value address is in a
886: register, define this macro as the register number.
887:
888: `STRUCT_VALUE_INCOMING'
889: If the incoming location is not a register, define
890: `STRUCT_VALUE_INCOMING' as an expression for an RTX for where
891: the called function should find the value. If it should find
892: the value on the stack, define this to create a `mem' which
893: refers to the frame pointer. If the value is a `mem', the
894: compiler assumes it is for an invisible first argument, and
895: leaves space for it when finding the first real argument.
896:
897: `REG_ALLOC_ORDER'
898: If defined, an initializer for a vector of integers, containing
899: the numbers of hard registers in the order in which the GNU CC
900: should prefer to use them (from most preferred to least).
901:
902: If this macro is not defined, registers are used lowest numbered
903: first (all else being equal).
904:
905: One use of this macro is on the 360, where the highest numbered
906: registers must always be saved and the save-multiple-registers
907: instruction supports only sequences of consecutive registers.
908: This macro is defined to cause the highest numbered allocatable
909: registers to be used first.
910:
911:
912:
913: File: gcc.info, Node: Register Classes, Next: Stack Layout, Prev: Registers, Up: Machine Macros
914:
915: Register Classes
916: ================
917:
918: On many machines, the numbered registers are not all equivalent. For
919: example, certain registers may not be allowed for indexed addressing;
920: certain registers may not be allowed in some instructions. These
921: machine restrictions are described to the compiler using "register
922: classes".
923:
924: You define a number of register classes, giving each one a name and
925: saying which of the registers belong to it. Then you can specify
926: register classes that are allowed as operands to particular
927: instruction patterns.
928:
929: In general, each register will belong to several classes. In fact,
930: one class must be named `ALL_REGS' and contain all the registers.
931: Another class must be named `NO_REGS' and contain no registers.
932: Often the union of two classes will be another class; however, this
933: is not required.
934:
935: One of the classes must be named `GENERAL_REGS'. There is nothing
936: terribly special about the name, but the operand constraint letters
937: `r' and `g' specify this class. If `GENERAL_REGS' is the same as
938: `ALL_REGS', just define it as a macro which expands to `ALL_REGS'.
939:
940: The way classes other than `GENERAL_REGS' are specified in operand
941: constraints is through machine-dependent operand constraint letters.
942: You can define such letters to correspond to various classes, then
943: use them in operand constraints.
944:
945: You should define a class for the union of two classes whenever some
946: instruction allows both classes. For example, if an instruction
947: allows either a floating-point (coprocessor) register or a general
948: register for a certain operand, you should define a class
949: `FLOAT_OR_GENERAL_REGS' which includes both of them. Otherwise you
950: will get suboptimal code.
951:
952: You must also specify certain redundant information about the
953: register classes: for each class, which classes contain it and which
954: ones are contained in it; for each pair of classes, the largest class
955: contained in their union.
956:
957: When a value occupying several consecutive registers is expected in a
958: certain class, all the registers used must belong to that class.
959: Therefore, register classes cannot be used to enforce a requirement
960: for a register pair to start with an even-numbered register. The way
961: to specify this requirement is with `HARD_REGNO_MODE_OK'.
962:
963: Register classes used for input-operands of bitwise-and or shift
964: instructions have a special requirement: each such class must have,
965: for each fixed-point machine mode, a subclass whose registers can
966: transfer that mode to or from memory. For example, on some machines,
967: the operations for single-byte values (`QImode') are limited to
968: certain registers. When this is so, each register class that is used
969: in a bitwise-and or shift instruction must have a subclass consisting
970: of registers from which single-byte values can be loaded or stored.
971: This is so that `PREFERRED_RELOAD_CLASS' can always have a possible
972: value to return.
973:
974: `enum reg_class'
975: An enumeral type that must be defined with all the register
976: class names as enumeral values. `NO_REGS' must be first.
977: `ALL_REGS' must be the last register class, followed by one more
978: enumeral value, `LIM_REG_CLASSES', which is not a register class
979: but rather tells how many classes there are.
980:
981: Each register class has a number, which is the value of casting
982: the class name to type `int'. The number serves as an index in
983: many of the tables described below.
984:
985: `N_REG_CLASSES'
986: The number of distinct register classes, defined as follows:
987:
988: #define N_REG_CLASSES (int) LIM_REG_CLASSES
989:
990: `REG_CLASS_NAMES'
991: An initializer containing the names of the register classes as C
992: string constants. These names are used in writing some of the
993: debugging dumps.
994:
995: `REG_CLASS_CONTENTS'
996: An initializer containing the contents of the register classes,
997: as integers which are bit masks. The Nth integer specifies the
998: contents of class N. The way the integer MASK is interpreted is
999: that register R is in the class if `MASK & (1 << R)' is 1.
1000:
1001: When the machine has more than 32 registers, an integer does not
1002: suffice. Then the integers are replaced by sub-initializers,
1003: braced groupings containing several integers. Each
1004: sub-initializer must be suitable as an initializer for the type
1005: `HARD_REG_SET' which is defined in `hard-reg-set.h'.
1006:
1007: `REGNO_REG_CLASS (REGNO)'
1008: A C expression whose value is a register class containing hard
1009: register REGNO. In general there is more that one such class;
1010: choose a class which is "minimal", meaning that no smaller class
1011: also contains the register.
1012:
1013: `BASE_REG_CLASS'
1014: A macro whose definition is the name of the class to which a
1015: valid base register must belong. A base register is one used in
1016: an address which is the register value plus a displacement.
1017:
1018: `INDEX_REG_CLASS'
1019: A macro whose definition is the name of the class to which a
1020: valid index register must belong. An index register is one used
1021: in an address where its value is either multiplied by a scale
1022: factor or added to another register (as well as added to a
1023: displacement).
1024:
1025: `REG_CLASS_FROM_LETTER (CHAR)'
1026: A C expression which defines the machine-dependent operand
1027: constraint letters for register classes. If CHAR is such a
1028: letter, the value should be the register class corresponding to
1029: it. Otherwise, the value should be `NO_REGS'.
1030:
1031: `REGNO_OK_FOR_BASE_P (NUM)'
1032: A C expression which is nonzero if register number NUM is
1033: suitable for use as a base register in operand addresses. It
1034: may be either a suitable hard register or a pseudo register that
1035: has been allocated such a hard register.
1036:
1037: `REGNO_OK_FOR_INDEX_P (NUM)'
1038: A C expression which is nonzero if register number NUM is
1039: suitable for use as an index register in operand addresses. It
1040: may be either a suitable hard register or a pseudo register that
1041: has been allocated such a hard register.
1042:
1043: The difference between an index register and a base register is
1044: that the index register may be scaled. If an address involves
1045: the sum of two registers, neither one of them scaled, then
1.1.1.4 ! root 1046: either one may be labeled the "base" and the other the "index";
! 1047: but whichever labeling is used must fit the machine's
1.1.1.3 root 1048: constraints of which registers may serve in each capacity. The
1049: compiler will try both labelings, looking for one that is valid,
1050: and will reload one or both registers only if neither labeling
1051: works.
1.1 root 1052:
1.1.1.3 root 1053: `PREFERRED_RELOAD_CLASS (X, CLASS)'
1054: A C expression that places additional restrictions on the
1055: register class to use when it is necessary to copy value X into
1056: a register in class CLASS. The value is a register class;
1057: perhaps CLASS, or perhaps another, smaller class. On many
1058: machines, the definition
1059:
1060: #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS
1061:
1062: is safe.
1063:
1064: Sometimes returning a more restrictive class makes better code.
1065: For example, on the 68000, when X is an integer constant that is
1066: in range for a `moveq' instruction, the value of this macro is
1067: always `DATA_REGS' as long as CLASS includes the data registers.
1068: Requiring a data register guarantees that a `moveq' will be used.
1069:
1070: If X is a `const_double', by returning `NO_REGS' you can force X
1071: into a memory constant. This is useful on certain machines
1072: where immediate floating values cannot be loaded into certain
1073: kinds of registers.
1074:
1075: In a shift instruction or a bitwise-and instruction, the mode of
1076: X, the value being reloaded, may not be the same as the mode of
1077: the instruction's operand. (They will both be fixed-point
1078: modes, however.) In such a case, CLASS may not be a safe value
1079: to return. CLASS is certainly valid for the instruction, but it
1080: may not be valid for reloading X. This problem can occur on
1081: machines such as the 68000 and 80386 where some registers can
1082: handle full-word values but cannot handle single-byte values.
1083:
1084: On such machines, this macro must examine the mode of X and
1085: return a subclass of CLASS which can handle loads and stores of
1086: that mode. On the 68000, where address registers cannot handle
1087: `QImode', if X has `QImode' then you must return `DATA_REGS'.
1088: If CLASS is `ADDR_REGS', then there is no correct value to
1089: return; but the shift and bitwise-and instructions don't use
1090: `ADDR_REGS', so this fatal case never arises.
1091:
1092: `CLASS_MAX_NREGS (CLASS, MODE)'
1093: A C expression for the maximum number of consecutive registers
1094: of class CLASS needed to hold a value of mode MODE.
1095:
1096: This is closely related to the macro `HARD_REGNO_NREGS'. In
1097: fact, the value of the macro `CLASS_MAX_NREGS (CLASS, MODE)'
1098: should be the maximum value of `HARD_REGNO_NREGS (REGNO, MODE)'
1099: for all REGNO values in the class CLASS.
1100:
1101: This macro helps control the handling of multiple-word values in
1102: the reload pass.
1103:
1104: Two other special macros describe which constants fit which
1105: constraint letters.
1106:
1107: `CONST_OK_FOR_LETTER_P (VALUE, C)'
1108: A C expression that defines the machine-dependent operand
1109: constraint letters that specify particular ranges of integer
1110: values. If C is one of those letters, the expression should
1111: check that VALUE, an integer, is in the appropriate range and
1112: return 1 if so, 0 otherwise. If C is not one of those letters,
1113: the value should be 0 regardless of VALUE.
1114:
1115: `CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C)'
1116: A C expression that defines the machine-dependent operand
1117: constraint letters that specify particular ranges of floating
1118: values. If C is one of those letters, the expression should
1119: check that VALUE, an RTX of code `const_double', is in the
1120: appropriate range and return 1 if so, 0 otherwise. If C is not
1121: one of those letters, the value should be 0 regardless of VALUE.
1.1 root 1122:
1123:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.