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