Return to internals-5 CVS log

Up to [GCC 1.x] / gcc

Annotation of gcc/internals-5, revision 1.1

1.1     ! root        1: Info file internals, produced by Makeinfo, -*- Text -*-
        !             2: from input file internals.texinfo.
        !             3: 
        !             4: 
        !             5: 
        !             6: This file documents the internals of the GNU compiler.
        !             7: 
        !             8: Copyright (C) 1988 Free Software Foundation, Inc.
        !             9: 
        !            10: Permission is granted to make and distribute verbatim copies of
        !            11: this manual provided the copyright notice and this permission notice
        !            12: are preserved on all copies.
        !            13: 
        !            14: Permission is granted to copy and distribute modified versions of this
        !            15: manual under the conditions for verbatim copying, provided also that the
        !            16: section entitled ``GNU CC General Public License'' is included exactly as
        !            17: in the original, and provided that the entire resulting derived work is
        !            18: distributed under the terms of a permission notice identical to this one.
        !            19: 
        !            20: Permission is granted to copy and distribute translations of this manual
        !            21: into another language, under the above conditions for modified versions,
        !            22: except that the section entitled ``GNU CC General Public License'' and
        !            23: this permission notice may be included in translations approved by the
        !            24: Free Software Foundation instead of in the original English.
        !            25: 
        !            26: 
        !            27: 
        !            28: 
        !            29: 
        !            30: 
        !            31: File: internals,  Node: Peephole Definitions,  Next: Expander Definitions,  Prev: Jump Patterns,  Up: Machine Desc
        !            32: 
        !            33: Defining Machine-Specific Peephole Optimizers
        !            34: =============================================
        !            35: 
        !            36: In addition to instruction patterns the `md' file may contain definitions
        !            37: of machine-specific peephole optimizations.
        !            38: 
        !            39: The combiner does not notice certain peephole optimizations when the data
        !            40: flow in the program does not suggest that it should try them.  For example,
        !            41: sometimes two consecutive insns related in purpose can be combined even
        !            42: though the second one does not appear to use a register computed in the
        !            43: first one.  A machine-specific peephole optimizer can detect such
        !            44: opportunities.
        !            45: 
        !            46: A definition looks like this:
        !            47: 
        !            48:      (define_peephole
        !            49:        [INSN-PATTERN-1
        !            50:         INSN-PATTERN-2
        !            51:         ...]
        !            52:        "CONDITION"
        !            53:        "TEMPLATE")
        !            54: 
        !            55: 
        !            56: In this skeleton, INSN-PATTERN-1 and so on are patterns to match
        !            57: consecutive instructions.  The optimization applies to a sequence of
        !            58: instructions when INSN-PATTERN-1 matches the first one, INSN-PATTERN-2
        !            59: matches the next, and so on.
        !            60: 
        !            61: INSN-PATTERN-1 and so on look *almost* like the second operand of
        !            62: `define_insn'.  There is one important difference: this pattern is an RTX,
        !            63: not a vector.  If the `define_insn' pattern would be a vector of one
        !            64: element, the INSN-PATTERN should be just that element, no vector.  If the
        !            65: `define_insn' pattern would have multiple elements then the INSN-PATTERN
        !            66: must place the vector inside an explicit `parallel' RTX.
        !            67: 
        !            68: The operands of the instructions are matched with `match_operands' and
        !            69: `match_dup', as usual).  What is not usual is that the operand numbers
        !            70: apply to all the instruction patterns in the definition.  So, you can check
        !            71: for identical operands in two instructions by using `match_operand' in one
        !            72: instruction and `match_dup' in the other.
        !            73: 
        !            74: The operand constraints used in `match_operand' patterns do not have any
        !            75: direct effect on the applicability of the optimization, but they will be
        !            76: validated afterward, so write constraints that are sure to fit whenever the
        !            77: optimization is applied.  It is safe to use `"g"' for each operand.
        !            78: 
        !            79: Once a sequence of instructions matches the patterns, the CONDITION is
        !            80: checked.  This is a C expression which makes the final decision whether to
        !            81: perform the optimization (do so if the expression is nonzero).  If
        !            82: CONDITION is omitted (in other words, the string is empty) then the
        !            83: optimization is applied to every sequence of instructions that matches the
        !            84: patterns.
        !            85: 
        !            86: The defined peephole optimizations are applied after register allocation is
        !            87: complete.  Therefore, the optimizer can check which operands have ended up
        !            88: in which kinds of registers, just by looking at the operands.
        !            89: 
        !            90: The way to refer to the operands in CONDITION is to write `operands[I]' for
        !            91: operand number I (as matched by `(match_operand I ...)').  Use the variable
        !            92: `insn' to refer to the last of the insns being matched; use `PREV_INSN' to
        !            93: find the preceding insns (but be careful to skip over any `note' insns that
        !            94: intervene).
        !            95: 
        !            96: When optimizing computations with intermediate results, you can use
        !            97: CONDITION to match only when the intermediate results are not used
        !            98: elsewhere.  Use the C expression `dead_or_set_p (INSN, OP)', where INSN is
        !            99: the insn in which you expect the value to be used for the last time (from
        !           100: the value of `insn', together with use of `PREV_INSN'), and OP is the
        !           101: intermediate value (from `operands[I]').
        !           102: 
        !           103: Applying the optimization means replacing the sequence of instructions with
        !           104: one new instruction.  The TEMPLATE controls ultimate output of assembler
        !           105: code for this combined instruction.  It works exactly like the template of
        !           106: a `define_insn'.  Operand numbers in this template are the same ones used
        !           107: in matching the original sequence of instructions.
        !           108: 
        !           109: The result of a defined peephole optimizer does not need to match any of
        !           110: the instruction patterns, and it does not have an opportunity to match
        !           111: them.  The peephole optimizer definition itself serves as the instruction
        !           112: pattern to control how the instruction is output.
        !           113: 
        !           114: Defined peephole optimizers are run in the last jump optimization pass, so
        !           115: the instructions they produce are never combined or rearranged
        !           116: automatically in any way.
        !           117: 
        !           118: Here is an example, taken from the 68000 machine description:
        !           119: 
        !           120:      (define_peephole
        !           121:        [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4)))
        !           122:         (set (match_operand:DF 0 "register_operand" "f")
        !           123:              (match_operand:DF 1 "register_operand" "ad"))]
        !           124:        "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])"
        !           125:        "*
        !           126:      {
        !           127:        rtx xoperands[2];
        !           128:        xoperands[1] = gen_rtx (REG, SImode, REGNO (operands[1]) + 1);
        !           129:      #ifdef MOTOROLA
        !           130:        output_asm_insn (\"move.l %1,(sp)\", xoperands);
        !           131:        output_asm_insn (\"move.l %1,-(sp)\", operands);
        !           132:        return \"fmove.d (sp)+,%0\";
        !           133:      #else
        !           134:        output_asm_insn (\"movel %1,sp@\", xoperands);
        !           135:        output_asm_insn (\"movel %1,sp@-\", operands);
        !           136:        return \"fmoved sp@+,%0\";
        !           137:      #endif
        !           138:      }
        !           139:      ")
        !           140: 
        !           141: 
        !           142: The effect of this optimization is to change
        !           143: 
        !           144:      jbsr _foobar
        !           145:      addql #4,sp
        !           146:      movel d1,sp@-
        !           147:      movel d0,sp@-
        !           148:      fmoved sp@+,fp0
        !           149: 
        !           150: 
        !           151: into
        !           152: 
        !           153:      jbsr _foobar
        !           154:      movel d1,sp@
        !           155:      movel d0,sp@-
        !           156:      fmoved sp@+,fp0
        !           157: 
        !           158: 
        !           159: 
        !           160: File: internals,  Node: Expander Definitions,  Prev: Peephole Definitions,  Up: Machine Desc
        !           161: 
        !           162: Defining RTL Sequences for Code Generation
        !           163: ==========================================
        !           164: 
        !           165: On some target machines, some standard pattern names for RTL generation
        !           166: cannot be handled with single insn, but a sequence of RTL insns can
        !           167: represent them.  For these target machines, you can write a `define_expand'
        !           168: to specify how to generate the sequence of RTL.
        !           169: 
        !           170: A `define_expand' is an RTL expression that looks almost like a
        !           171: `define_insn'; but, unlike the latter, a `define_expand' is used only for
        !           172: RTL generation and it can produce more than one RTL insn.
        !           173: 
        !           174: A `define_expand' RTX has four operands:
        !           175: 
        !           176:    * The name.  Each `define_expand' must have a name, since the only use
        !           177:      for it is to refer to it by name.
        !           178: 
        !           179:    * The RTL template.  This is just like the RTL template for a
        !           180:      `define_peephole' in that it is a vector of RTL expressions each being
        !           181:      one insn.
        !           182: 
        !           183:    * The condition, a string containing a C expression.  This expression is
        !           184:      used to express how the availability of this pattern depends on
        !           185:      subclasses of target machine, selected by command-line options when
        !           186:      GNU CC is run.  This is just like the condition of a `define_insn'
        !           187:      that has a standard name.
        !           188: 
        !           189:    * The preparation statements, a string containing zero or more C
        !           190:      statements which are to be executed before RTL code is generated from
        !           191:      the RTL template.
        !           192: 
        !           193:      Usually these statements prepare temporary registers for use as
        !           194:      internal operands in the RTL template, but they can also generate RTL
        !           195:      insns directly by calling routines such as `emit_insn', etc.  Any such
        !           196:      insns precede the ones that come from the RTL template.
        !           197: 
        !           198: The RTL template, in addition to controlling generation of RTL insns, also
        !           199: describes the operands that need to be specified when this pattern is used.
        !           200:  In particular, it gives a predicate for each operand.
        !           201: 
        !           202: A true operand, which need to be specified in order to generate RTL from
        !           203: the pattern, should be described with a `match_operand' in its first
        !           204: occurrence in the RTL template.  This enters information on the operand's
        !           205: predicate into the tables that record such things.  GNU CC uses the
        !           206: information to preload the operand into a register if that is required for
        !           207: valid RTL code.  If the operand is referred to more than once, subsequent
        !           208: references should use `match_dup'.
        !           209: 
        !           210: The RTL template may also refer to internal ``operands'' which are
        !           211: temporary registers or labels used only within the sequence made by the
        !           212: `define_expand'.  Internal operands are substituted into the RTL template
        !           213: with `match_dup', never with `match_operand'.  The values of the internal
        !           214: operands are not passed in as arguments by the compiler when it requests
        !           215: use of this pattern.  Instead, they are computed within the pattern, in the
        !           216: preparation statements.  These statements compute the values and store them
        !           217: into the appropriate elements of `operands' so that `match_dup' can find
        !           218: them.
        !           219: 
        !           220: There are two special macros defined for use in the preparation statements:
        !           221: `DONE' and `FAIL'.  Use them with a following semicolon, as a statement.
        !           222: 
        !           223: `DONE'
        !           224:      Use the `DONE' macro to end RTL generation for the pattern.  The only
        !           225:      RTL insns resulting from the pattern on this occasion will be those
        !           226:      already emitted by explicit calls to `emit_insn' within the
        !           227:      preparation statements; the RTL template will not be generated.
        !           228: 
        !           229: `FAIL'
        !           230:      Make the pattern fail on this occasion.  When a pattern fails, it
        !           231:      means that the pattern was not truly available.  The calling routines
        !           232:      in the compiler will try other strategies for code generation using
        !           233:      other patterns.
        !           234: 
        !           235:      Failure is currently supported only for binary operations (addition,
        !           236:      multiplication, shifting, etc.).
        !           237: 
        !           238:      Do not emit any insns explicitly with `emit_insn' before failing.
        !           239: 
        !           240: Here is an example, the definition of left-shift for the SPUR chip:
        !           241: 
        !           242:      (define_expand "ashlsi3"
        !           243:        [(set (match_operand:SI 0 "register_operand" "")
        !           244:              (ashift:SI
        !           245:                (match_operand:SI 1 "register_operand" "")
        !           246:                (match_operand:SI 2 "nonmemory_operand" "")))]
        !           247:        ""
        !           248:        "
        !           249:      {
        !           250:        if (GET_CODE (operands[2]) != CONST_INT
        !           251:            || (unsigned) INTVAL (operands[2]) > 3)
        !           252:          FAIL;
        !           253:      }")
        !           254: 
        !           255: 
        !           256: This example uses `define_expand' so that it can generate an RTL insn for
        !           257: shifting when the shift-count is in the supported range of 0 to 3 but fail
        !           258: in other cases where machine insns aren't available.  When it fails, the
        !           259: compiler tries another strategy using different patterns (such as, a
        !           260: library call).
        !           261: 
        !           262: If the compiler were able to handle nontrivial condition-strings in
        !           263: patterns with names, then there would be possible to use a `define_insn' in
        !           264: that case.  Here is another case (zero-extension on the 68000) which makes
        !           265: more use of the power of `define_expand':
        !           266: 
        !           267:      (define_expand "zero_extendhisi2"
        !           268:        [(set (match_operand:SI 0 "general_operand" "")
        !           269:              (const_int 0))
        !           270:         (set (strict_low_part 
        !           271:                (subreg:HI
        !           272:                  (match_operand:SI 0 "general_operand" "")
        !           273:                  0))
        !           274:              (match_operand:HI 1 "general_operand" ""))]
        !           275:        ""
        !           276:        "operands[1] = make_safe_from (operands[1], operands[0]);")
        !           277: 
        !           278: 
        !           279: Here two RTL insns are generated, one to clear the entire output operand
        !           280: and the other to copy the input operand into its low half.  This sequence
        !           281: is incorrect if the input operand refers to [the old value of] the output
        !           282: operand, so the preparation statement makes sure this isn't so.  The
        !           283: function `make_safe_from' copies the `operands[1]' into a temporary
        !           284: register if it refers to `operands[0]'.  It does this by emitting another
        !           285: RTL insn.
        !           286: 
        !           287: Finally, a third example shows the use of an internal operand. 
        !           288: Zero-extension on the SPUR chip is done by `and'-ing the result against a
        !           289: halfword mask.  But this mask cannot be represented by a `const_int'
        !           290: because the constant value is too large to be legitimate on this machine. 
        !           291: So it must be copied into a register with `force_reg' and then the register
        !           292: used in the `and'.
        !           293: 
        !           294:      (define_expand "zero_extendhisi2"
        !           295:        [(set (match_operand:SI 0 "register_operand" "")
        !           296:              (and:SI (subreg:SI
        !           297:                        (match_operand:HI 1 "register_operand" "")
        !           298:                        0)
        !           299:                      (match_dup 2)))]
        !           300:        ""
        !           301:        "operands[2]
        !           302:           = force_reg (SImode, gen_rtx (CONST_INT,
        !           303:                                         VOIDmode, 65535)); ")
        !           304: 
        !           305: 
        !           306: 
        !           307: File: internals,  Node: Machine Macros,  Next: Config,  Prev: Machine Desc,  Up: Top
        !           308: 
        !           309: Machine Description Macros
        !           310: **************************
        !           311: 
        !           312: The other half of the machine description is a C header file conventionally
        !           313: given the name `tm-MACHINE.h'.  The file `tm.h' should be a link to it. 
        !           314: The header file `config.h' includes `tm.h' and most compiler source files
        !           315: include `config.h'.
        !           316: 
        !           317: 
        !           318: * Menu:
        !           319: 
        !           320: * Run-time Target::     Defining -m options like -m68000 and -m68020.
        !           321: * Storage Layout::      Defining sizes and alignments of data types.
        !           322: * Registers::           Naming and describing the hardware registers.
        !           323: * Register Classes::    Defining the classes of hardware registers.
        !           324: * Stack Layout::        Defining which way the stack grows and by how much.
        !           325: * Library Names::       Specifying names of subroutines to call automatically.
        !           326: * Addressing Modes::    Defining addressing modes valid for memory operands.
        !           327: * Condition Code::      Defining how insns update the condition code.
        !           328: * Assembler Format::    Defining how to write insns and pseudo-ops to output.
        !           329: * Misc::                Everything else.
        !           330: 
        !           331: 
        !           332: 
        !           333: File: internals,  Node: Run-time Target,  Next: Storage Layout,  Prev: Machine Macros,  Up: Machine Macros
        !           334: 
        !           335: Run-time Target Specification
        !           336: =============================
        !           337: 
        !           338: `CPP_PREDEFINES'
        !           339:      Define this to be a string constant containing `-D' options to define
        !           340:      the predefined macros that identify this machine and system.
        !           341: 
        !           342:      For example, on the Sun, one can use the value
        !           343: 
        !           344:           "-Dmc68000 -Dsun -Dunix"
        !           345: 
        !           346: 
        !           347: `extern int target_flags;'
        !           348:      This declaration should be present.
        !           349: 
        !           350: `TARGET_...'
        !           351:      This series of macros is to allow compiler command arguments to enable
        !           352:      or disable the use of optional features of the target machine.  For
        !           353:      example, one machine description serves both the 68000 and the 68020;
        !           354:      a command argument tells the compiler whether it should use 68020-only
        !           355:      instructions or not.  This command argument works by means of a macro
        !           356:      `TARGET_68020' that tests a bit in `target_flags'.
        !           357: 
        !           358:      Define a macro `TARGET_FEATURENAME' for each such option.  Its
        !           359:      definition should test a bit in `target_flags'; for example:
        !           360: 
        !           361:           #define TARGET_68020 (target_flags & 1)
        !           362: 
        !           363: 
        !           364:      One place where these macros are used is in the condition-expressions
        !           365:      of instruction patterns.  Note how `TARGET_68020' appears frequently
        !           366:      in the 68000 machine description file, `m68k.md'.  Another place they
        !           367:      are used is in the definitions of the other macros in the
        !           368:      `tm-MACHINE.h' file.
        !           369: 
        !           370: `TARGET_SWITCHES'
        !           371:      This macro defines names of command options to set and clear bits in
        !           372:      `target_flags'.  Its definition is an initializer with a subgrouping
        !           373:      for each command option.
        !           374: 
        !           375:      Each subgrouping contains a string constant, that defines the option
        !           376:      name, and a number, which contains the bits to set in `target_flags'. 
        !           377:      A negative number says to clear bits instead; the negative of the
        !           378:      number is which bits to clear.  The actual option name is made by
        !           379:      appending `-m' to the specified name.
        !           380: 
        !           381:      One of the subgroupings should have a null string.  The number in this
        !           382:      grouping is the default value for `target_flags'.  Any target options
        !           383:      act starting with that value.
        !           384: 
        !           385:      Here is an example which defines `-m68000' and `-m68020' with opposite
        !           386:      meanings, and picks the latter as the default:
        !           387: 
        !           388:           #define TARGET_SWITCHES \
        !           389:             { { "68020", 1},      \
        !           390:               { "68000", -1},     \
        !           391:               { "", 1}}
        !           392: 
        !           393: 
        !           394: Sometimes certain combinations of command options do not make sense on a
        !           395: particular target machine.  You can define a macro `OVERRIDE_OPTIONS' to
        !           396: take account of this.  This macro, if defined, is executed once just after
        !           397: all the command options have been parsed.
        !           398: 
        !           399: 
        !           400: File: internals,  Node: Storage Layout,  Next: Registers,  Prev: Run-time Target,  Up: Machine Macros
        !           401: 
        !           402: Storage Layout
        !           403: ==============
        !           404: 
        !           405: Note that the definitions of the macros in this table which are sizes or
        !           406: alignments measured in bits do not need to be constant.  They can be C
        !           407: expressions that refer to static variables, such as the `target_flags'. 
        !           408: *note Run-time Target::.
        !           409: 
        !           410: `BITS_BIG_ENDIAN'
        !           411:      Define this macro if the most significant bit in a byte has the lowest
        !           412:      number.  This means that bit-field instructions count from the most
        !           413:      significant bit.  If the machine has no bit-field instructions, this
        !           414:      macro is irrelevant.
        !           415: 
        !           416: `BYTES_BIG_ENDIAN'
        !           417:      Define this macro if the most significant byte in a word has the
        !           418:      lowest number.
        !           419: 
        !           420: `WORDS_BIG_ENDIAN'
        !           421:      Define this macro if, in a multiword object, the most significant word
        !           422:      has the lowest number.
        !           423: 
        !           424: `BITS_PER_UNIT'
        !           425:      Number of bits in an addressable storage unit (byte); normally 8.
        !           426: 
        !           427: `BITS_PER_WORD'
        !           428:      Number of bits in a word; normally 32.
        !           429: 
        !           430: `UNITS_PER_WORD'
        !           431:      Number of storage units in a word; normally 4.
        !           432: 
        !           433: `POINTER_SIZE'
        !           434:      Width of a pointer, in bits.
        !           435: 
        !           436: `PARM_BOUNDARY'
        !           437:      Alignment required for function parameters on the stack, in bits.
        !           438: 
        !           439: `STACK_BOUNDARY'
        !           440:      Define this macro if you wish to preserve a certain alignment for the
        !           441:      stack pointer at all times.  The definition is a C expression for the
        !           442:      desired alignment (measured in bits).
        !           443: 
        !           444: `FUNCTION_BOUNDARY'
        !           445:      Alignment required for a function entry point, in bits.
        !           446: 
        !           447: `BIGGEST_ALIGNMENT'
        !           448:      Biggest alignment that any data type can require on this machine, in
        !           449:      bits.
        !           450: 
        !           451: `EMPTY_FIELD_ALIGNMENT'
        !           452:      Alignment in bits to be given to a structure bit field that follows an
        !           453:      empty field such as `int : 0;'.
        !           454: 
        !           455: `STRUCTURE_SIZE_BOUNDARY'
        !           456:      Number of bits which any structure or union's size must be a multiple
        !           457:      of.  Each structure or union's size is rounded up to a multiple of this.
        !           458: 
        !           459:      If you do not define this macro, the default is the same as
        !           460:      `BITS_PER_UNIT'.
        !           461: 
        !           462: `STRICT_ALIGNMENT'
        !           463:      Define this if instructions will fail to work if given data not on the
        !           464:      nominal alignment.  If instructions will merely go slower in that
        !           465:      case, do not define this macro.
        !           466: 
        !           467: 
        !           468: File: internals,  Node: Registers,  Next: Register Classes,  Prev: Storage Layout,  Up: Machine Macros
        !           469: 
        !           470: Register Usage
        !           471: ==============
        !           472: 
        !           473: `FIRST_PSEUDO_REGISTER'
        !           474:      Number of hardware registers known to the compiler.  They receive
        !           475:      numbers 0 through `FIRST_PSEUDO_REGISTER-1'; thus, the first pseudo
        !           476:      register's number really is assigned the number `FIRST_PSEUDO_REGISTER'.
        !           477: 
        !           478: `FIXED_REGISTERS'
        !           479:      An initializer that says which registers are used for fixed purposes
        !           480:      all throughout the compiled code and are therefore not available for
        !           481:      general allocation.  These would include the stack pointer, the frame
        !           482:      pointer, the program counter on machines where that is considered one
        !           483:      of the addressable registers, and any other numbered register with a
        !           484:      standard use.
        !           485: 
        !           486:      This information is expressed as a sequence of numbers, separated by
        !           487:      commas and surrounded by braces.  The Nth number is 1 if register N is
        !           488:      fixed, 0 otherwise.
        !           489: 
        !           490:      The table initialized from this macro, and the table initialized by
        !           491:      the following one, may be overridden at run time either automatically,
        !           492:      by the actions of the macro `CONDITIONAL_REGISTER_USAGE', or by the
        !           493:      user with the command options `-ffixed-REG', `-fcall-used-REG' and
        !           494:      `-fcall-saved-REG'.
        !           495: 
        !           496: `CALL_USED_REGISTERS'
        !           497:      Like `FIXED_REGISTERS' but has 1 for each register that is clobbered
        !           498:      (in general) by function calls as well as for fixed registers.  This
        !           499:      macro therefore identifies the registers that are not available for
        !           500:      general allocation of values that must live across function calls.
        !           501: 
        !           502:      If a register has 0 in `CALL_USED_REGISTERS', the compiler
        !           503:      automatically saves it on function entry and restores it on function
        !           504:      exit, if the register is used within the function.
        !           505: 
        !           506: `CONDITIONAL_REGISTER_USAGE'
        !           507:      Zero or more C statements that may conditionally modify two variables
        !           508:      `fixed_regs' and `call_used_regs' (both of type `char []') after they
        !           509:      have been initialized from the two preceding macros.
        !           510: 
        !           511:      This is necessary in case the fixed or call-clobbered registers depend
        !           512:      on target flags.
        !           513: 
        !           514:      You need not define this macro if it has no work to do.
        !           515: 
        !           516: `HARD_REGNO_REGS (REGNO, MODE)'
        !           517:      A C expression for the number of consecutive hard registers, starting
        !           518:      at register number REGNO, required to hold a value of mode MODE.
        !           519: 
        !           520:      On a machine where all registers are exactly one word, a suitable
        !           521:      definition of this macro is
        !           522: 
        !           523:           #define HARD_REGNO_NREGS(REGNO, MODE)            \
        !           524:              ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1)  \
        !           525:               / UNITS_PER_WORD))
        !           526: 
        !           527: 
        !           528: `HARD_REGNO_MODE_OK (REGNO, MODE)'
        !           529:      A C expression that is nonzero if it is permissible to store a value
        !           530:      of mode MODE in hard register number REGNO (or in several registers
        !           531:      starting with that one).  For a machine where all registers are
        !           532:      equivalent, a suitable definition is
        !           533: 
        !           534:           #define HARD_REGNO_MODE_OK(REGNO, MODE) 1
        !           535: 
        !           536: 
        !           537:      It is not necessary for this macro to check for fixed register numbers
        !           538:      because the allocation mechanism considers them to be always occupied.
        !           539: 
        !           540:      Many machines have special registers for floating point arithmetic. 
        !           541:      Often people assume that floating point machine modes are allowed only
        !           542:      in floating point registers.  This is not true.  Any registers that
        !           543:      can hold integers can safely *hold* a floating point machine mode,
        !           544:      whether or not floating arithmetic can be done on it in those registers.
        !           545: 
        !           546:      The true significance of special floating registers is rather than
        !           547:      non-floating-point machine modes *may not* go in those registers. 
        !           548:      This is true if the floating registers normalize any value stored in
        !           549:      them, because storing a non-floating value there would garble it.  If
        !           550:      the floating registers do not automatically normalize, if you can
        !           551:      store any bit pattern in one and retrieve it unchanged without a trap,
        !           552:      then any machine mode may go in a floating register and this macro
        !           553:      should say so.
        !           554: 
        !           555:      Sometimes there are floating registers that are especially slow to
        !           556:      access, so that it is better to store a value in a stack frame than in
        !           557:      such a register if floating point arithmetic is not being done.  As
        !           558:      long as the floating registers are not in class `GENERAL_REGS', they
        !           559:      will not be used unless some insn's constraint asks for one.
        !           560: 
        !           561:      It is obligatory to support floating point `move' instructions into
        !           562:      and out of general registers, because unions and structures (which
        !           563:      have modes `SImode' or `DImode') can be in those registers and they
        !           564:      may have floating point members.
        !           565: 
        !           566: `MODES_TIEABLE_P (MODE1, MODE2)'
        !           567:      A C expression that is nonzero if it is desirable to choose register
        !           568:      allocation so as to avoid move instructions between a value of mode
        !           569:      MODE1 and a value of mode MODE2.
        !           570: 
        !           571:      If `HARD_REGNO_MODE_OK (R, MODE1)' and `HARD_REGNO_MODE_OK (R, MODE2)'
        !           572:      are ever different for any R, then `MODES_TIEABLE_P (MODE1, MODE2)'
        !           573:      must be zero.
        !           574: 
        !           575: `PC_REGNUM'
        !           576:      If the program counter has a register number, define this as that
        !           577:      register number.  Otherwise, do not define it.
        !           578: 
        !           579: `STACK_POINTER_REGNUM'
        !           580:      The register number of the stack pointer register, which must also be
        !           581:      a fixed register according to `FIXED_REGISTERS'.  On many machines,
        !           582:      the hardware determines which register this is.
        !           583: 
        !           584: `FRAME_POINTER_REGNUM'
        !           585:      The register number of the frame pointer register, which is used to
        !           586:      access automatic variables in the stack frame.  On some machines, the
        !           587:      hardware determines which register this is.  On other machines, you
        !           588:      can choose any register you wish for this purpose.
        !           589: 
        !           590: `FRAME_POINTER_REQUIRED'
        !           591:      A C expression which is nonzero if a function must have and use a
        !           592:      frame pointer.  This expression is evaluated in the reload pass, in
        !           593:      the function `reload', and it can in principle examine the current
        !           594:      function and decide according to the facts, but on most machines the
        !           595:      constant 0 or the constant 1 suffices.  Use 0 when the machine allows
        !           596:      code to be generated with no frame pointer, and doing so saves some
        !           597:      time or space.  Use 1 when there is no possible advantage to avoiding
        !           598:      a frame pointer.
        !           599: 
        !           600:      In certain cases, the compiler does not know how to do without a frame
        !           601:      pointer.  The compiler recognizes those cases and automatically gives
        !           602:      the function a frame pointer regardless of what
        !           603:      `FRAME_POINTER_REQUIRED' says.  You don't need to worry about them.
        !           604: 
        !           605:      In a function that does not require a frame pointer, the frame pointer
        !           606:      register can be allocated for ordinary usage, provided it is not
        !           607:      marked as a fixed register.  See `FIXED_REGISTERS' for more information.
        !           608: 
        !           609: `ARG_POINTER_REGNUM'
        !           610:      The register number of the arg pointer register, which is used to
        !           611:      access the function's argument list.  On some machines, this is the
        !           612:      same as the frame pointer register.  On some machines, the hardware
        !           613:      determines which register this is.  On other machines, you can choose
        !           614:      any register you wish for this purpose.  It must in any case be a
        !           615:      fixed register according to `FIXED_REGISTERS'.
        !           616: 
        !           617: `STATIC_CHAIN_REGNUM'
        !           618:      The register number used for passing a function's static chain
        !           619:      pointer.  This is needed for languages such as Pascal and Algol where
        !           620:      functions defined within other functions can access the local
        !           621:      variables of the outer functions; it is not currently used because C
        !           622:      does not provide this feature.
        !           623: 
        !           624:      The static chain register need not be a fixed register.
        !           625: 
        !           626: `STRUCT_VALUE_REGNUM'
        !           627:      When a function's value's mode is `BLKmode', the value is not returned
        !           628:      according to `FUNCTION_VALUE'.  Instead, the caller passes the address
        !           629:      of a block of memory in which the value should be stored. 
        !           630:      `STRUCT_VALUE_REGNUM' is the register in which this address is passed.
        !           631: 
        !           632: 
        !           633: File: internals,  Node: Register Classes,  Next: Stack Layout,  Prev: Registers,  Up: Machine Macros
        !           634: 
        !           635: Register Classes
        !           636: ================
        !           637: 
        !           638: On many machines, the numbered registers are not all equivalent.  For
        !           639: example, certain registers may not be allowed for indexed addressing;
        !           640: certain registers may not be allowed in some instructions.  These machine
        !           641: restrictions are described to the compiler using "register classes".
        !           642: 
        !           643: You define a number of register classes, giving each one a name and saying
        !           644: which of the registers belong to it.  Then you can specify register classes
        !           645: that are allowed as operands to particular instruction patterns.
        !           646: 
        !           647: In general, each register will belong to several classes.  In fact, one
        !           648: class must be named `ALL_REGS' and contain all the registers.  Another
        !           649: class must be named `NO_REGS' and contain no registers.  Often the union of
        !           650: two classes will be another class; however, this is not required.
        !           651: 
        !           652: One of the classes must be named `GENERAL_REGS'.  There is nothing terribly
        !           653: special about the name, but the operand constraint letters `r' and `g'
        !           654: specify this class.  If `GENERAL_REGS' is the same as `ALL_REGS', just
        !           655: define it as a macro which expands to `ALL_REGS'.
        !           656: 
        !           657: The way classes other than `GENERAL_REGS' are specified in operand
        !           658: constraints is through machine-dependent operand constraint letters.  You
        !           659: can define such letters to correspond to various classes, then use them in
        !           660: operand constraints.
        !           661: 
        !           662: You should define a class for the union of two classes whenever some
        !           663: instruction allows both classes.  For example, if an instruction allows
        !           664: either a floating-point (coprocessor) register or a general register for a
        !           665: certain operand, you should define a class `FLOAT_OR_GENERAL_REGS' which
        !           666: includes both of them.  Otherwise you will get suboptimal code.
        !           667: 
        !           668: You must also specify certain redundant information about the register
        !           669: classes: for each class, which classes contain it and which ones are
        !           670: contained in it; for each pair of classes, the largest class contained in
        !           671: their union.
        !           672: 
        !           673: `enum reg_class'
        !           674:      An enumeral type that must be defined with all the register class
        !           675:      names as enumeral values.  `NO_REGS' must be first.  `ALL_REGS' must
        !           676:      be the last register class, followed by one more enumeral value,
        !           677:      `LIM_REG_CLASSES', which is not a register class but rather tells how
        !           678:      many classes there are.
        !           679: 
        !           680:      Each register class has a number, which is the value of casting the
        !           681:      class name to type `int'.  The number serves as an index in many of
        !           682:      the tables described below.
        !           683: 
        !           684: `REG_CLASS_NAMES'
        !           685:      An initializer containing the names of the register classes as C
        !           686:      string constants.  These names are used in writing some of the
        !           687:      debugging dumps.
        !           688: 
        !           689: `REG_CLASS_CONTENTS'
        !           690:      An initializer containing the contents of the register classes, as
        !           691:      integers which are bit masks.  The Nth integer specifies the contents
        !           692:      of class N.  The way the integer MASK is interpreted is that register
        !           693:      R is in the class if `MASK & (1 << R)' is 1.
        !           694: 
        !           695:      When the machine has more than 32 registers, an integer does not
        !           696:      suffice.  Then the integers are replaced by sub-initializers, braced
        !           697:      groupings containing several integers.  Each sub-initializer must be
        !           698:      suitable as an initializer for the type `HARD_REG_SET' which is
        !           699:      defined in `hard-reg-set.h'.
        !           700: 
        !           701: `REGNO_REG_CLASS (REGNO)'
        !           702:      A C expression whose value is a register class containing hard
        !           703:      regiSTER REGNO.  In general there is more that one such class; choose
        !           704:      a class which is "minimal", meaning that no smaller class also
        !           705:      contains the register.
        !           706: 
        !           707: `INDEX_REG_CLASS'
        !           708:      A macro whose definition is the name of the class to which a valid
        !           709:      index register must belong.
        !           710: 
        !           711: `REG_CLASS_FROM_LETTER (CHAR)'
        !           712:      A C expression which defines the machine-dependent operand constraint
        !           713:      letters for register classes.  If CHAR is such a letter, the value
        !           714:      should be the register class corresponding to it.  Otherwise, the
        !           715:      value should be `NO_REGS'.
        !           716: 
        !           717: `REGNO_OK_FOR_BASE_P (NUM)'
        !           718:      A C expression which is nonzero if register number NUM is suitable for
        !           719:      use as a base register in operand addresses.  It may be either a
        !           720:      suitable hard register or a pseudo register that has been allocated
        !           721:      such a hard register.
        !           722: 
        !           723: `REGNO_OK_FOR_INDEX_P (NUM)'
        !           724:      A C expression which is nonzero if register number NUM is suitable for
        !           725:      use as an index register in operand addresses.  It may be either a
        !           726:      suitable hard register or a pseudo register that has been allocated
        !           727:      such a hard register.
        !           728: 
        !           729:      The difference between an index register and a base register is that
        !           730:      the index register may be scaled.  If an address involves the sum of
        !           731:      two registers, neither one of them scaled, then either one may be
        !           732:      labeled the ``base'' and the other the ``index''; but whichever
        !           733:      labeling is used must fit the machine's constraints of which registers
        !           734:      may serve in each capacity.  The compiler will try both labelings,
        !           735:      looking for one that is valid, and reload one or both registers only
        !           736:      if neither labeling works.
        !           737: 
        !           738: `PREFERRED_RELOAD_CLASS (X, CLASS)'
        !           739:      A C expression that places additional restrictions on the register
        !           740:      class to use when it is necessary to copy value X into a register in
        !           741:      class CLASS.  The value is a register class; perhaps CLASS, or perhaps
        !           742:      another, smaller class.  CLASS is always safe as a value.  In fact,
        !           743:      the definition
        !           744: 
        !           745:           #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS
        !           746: 
        !           747: 
        !           748:      is always safe.  However, sometimes returning a more restrictive class
        !           749:      makes better code.  For example, on the 68000, when X is an integer
        !           750:      constant that is in range for a `moveq' instruction, the value of this
        !           751:      macro is always `DATA_REGS' as long as CLASS includes the data
        !           752:      registers.  Requiring a data register guarantees that a `moveq' will
        !           753:      be used.
        !           754: 
        !           755: `CLASS_MAX_NREGS (CLASS, MODE)'
        !           756:      A C expression for the maximum number of consecutive registers of
        !           757:      cLASS CLASS needed to hold a value of mode MODE.
        !           758: 
        !           759:      This is closely related to the macro `HARD_REGNO_NREGS'.  In fact, the
        !           760:      value of the macro `CLASS_MAX_NREGS (CLASS, MODE)' should be the
        !           761:      maximum value of `HARD_REGNO_NREGS (REGNO, MODE)' for all REGNO values
        !           762:      in the class CLASS.
        !           763: 
        !           764:      This macro helps control the handling of multiple-word values in the
        !           765:      reload pass.
        !           766: 
        !           767: Two other special macros describe which constants fit which constraint
        !           768: letters.
        !           769: 
        !           770: `CONST_OK_FOR_LETTER_P (VALUE, C)'
        !           771:      A C expression that defines the machine-dependent operand constraint
        !           772:      letters that specify particular ranges of integer values.  If C is one
        !           773:      of those letters, the expression should check that VALUE, an integer,
        !           774:      is in the appropriate range and return 1 if so, 0 otherwise.  If C is
        !           775:      not one of those letters, the value should be 0 regardless of VALUE.
        !           776: 
        !           777: `CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C)'
        !           778:      A C expression that defines the machine-dependent operand constraint
        !           779:      letters that specify particular ranges of floating values.  If C is
        !           780:      one of those letters, the expression should check that VALUE, an RTX
        !           781:      of code `const_double', is in the appropriate range and return 1 if
        !           782:      so, 0 otherwise.  If C is not one of those letters, the value should
        !           783:      be 0 regardless of VALUE.
        !           784: 
        !           785: 
        !           786: File: internals,  Node: Stack Layout,  Next: Library Names,  Prev: Register Classes,  Up: Machine Macros
        !           787: 
        !           788: Describing Stack Layout
        !           789: =======================
        !           790: 
        !           791: `STACK_GROWS_DOWNWARD'
        !           792:      Define this macro if pushing a word onto the stack moves the stack
        !           793:      pointer to a smaller address.
        !           794: 
        !           795:      When we say, ``define this macro if ...,'' it means that the compiler
        !           796:      checks this macro only with `#ifdef' so the precise definition used
        !           797:      does not matter.
        !           798: 
        !           799: `FRAME_GROWS_DOWNWARD'
        !           800:      Define this macro if the addresses of local variable slots are at
        !           801:      negative offsets from the frame pointer.
        !           802: 
        !           803: `STARTING_FRAME_OFFSET'
        !           804:      Offset from the frame pointer to the first local variable slot to be
        !           805:      allocated.
        !           806: 
        !           807:      If `FRAME_GROWS_DOWNWARD', the next slot's offset is found by
        !           808:      subtracting the length of the first slot from `STARTING_FRAME_OFFSET'.
        !           809:       Otherwise, it is found by adding the length of the first slot to the
        !           810:      value `STARTING_FRAME_OFFSET'.
        !           811: 
        !           812: `PUSH_ROUNDING (NPUSHED)'
        !           813:      A C expression that is the number of bytes actually pushed onto the
        !           814:      stack when an instruction attempts to push NPUSHED bytes.
        !           815: 
        !           816:      If the target machine does not have a push instruction, do not define
        !           817:      this macro.  That directs GNU CC to use an alternate strategy: to
        !           818:      allocate the entire argument block and then store the arguments into it.
        !           819: 
        !           820:      On some machines, the definition
        !           821: 
        !           822:           #define PUSH_ROUNDING(BYTES) (BYTES)
        !           823: 
        !           824: 
        !           825:      will suffice.  But on other machines, instructions that appear to push
        !           826:      one byte actually push two bytes in an attempt to maintain alignment. 
        !           827:      Then the definition should be
        !           828: 
        !           829:           #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1)
        !           830: 
        !           831: 
        !           832: `FIRST_PARM_OFFSET'
        !           833:      Offset from the argument pointer register to the first argument's
        !           834:      address.
        !           835: 
        !           836: `RETURN_POPS_ARGS (FUNTYPE)'
        !           837:      A C expression that should be 1 if a function pops its own arguments
        !           838:      on returning, or 0 if the function pops no arguments and the caller
        !           839:      must therefore pop them all after the function returns.
        !           840: 
        !           841:      FUNTYPE is a C variable whose value is a tree node that describes the
        !           842:      function in question.  Normally it is a node of type `FUNCTION_TYPE'
        !           843:      that describes the data type of the function.  From this it is
        !           844:      possible to obtain the data types of the value and arguments (if known).
        !           845: 
        !           846:      When a call to a library function is being considered, FUNTYPE will
        !           847:      contain an identifier node for the library function.  Thus, if you
        !           848:      need to distinguish among various library functions, you can do so by
        !           849:      their names.  Note that ``library function'' in this context means a
        !           850:      function used to perform arithmetic, whose name is known specially in
        !           851:      the compiler and was not mentioned in the C code being compiled.
        !           852: 
        !           853:      On the Vax, all functions always pop their arguments, so the
        !           854:      definition of this macro is 1.  On the 68000, using the standard
        !           855:      calling convention, no functions pop their arguments, so the value of
        !           856:      the macro is always 0 in this case.  But an alternative calling
        !           857:      convention is available in which functions that take a fixed number of
        !           858:      arguments pop them but other functions (such as `printf') pop nothing
        !           859:      (the caller pops all).  When this convention is in use, FUNTYPE is
        !           860:      examined to determine whether a function takes a fixed number of
        !           861:      arguments.
        !           862: 
        !           863: `FUNCTION_VALUE (VALTYPE, FUNC)'
        !           864:      A C expression to create an RTX representing the place where a
        !           865:      function returns a value of data type VALTYPE.  VALTYPE is a tree node
        !           866:      representing a data type.  Write `TYPE_MODE (VALTYPE)' to get the
        !           867:      machine mode used to represent that type.  On many machines, only the
        !           868:      mode is relevant.  (Actually, on most machines, scalar values are
        !           869:      returned in the same place regardless of mode).
        !           870: 
        !           871:      If the precise function being called is known, FUNC is a tree node
        !           872:      (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer.  This
        !           873:      makes it possible to use a different value-returning convention for
        !           874:      specific functions when all their calls are known.
        !           875: 
        !           876: `FUNCTION_OUTGOING_VALUE (VALTYPE, FUNC)'
        !           877:      Define this macro if the target machine has ``register windows'' so
        !           878:      that the register in which a function returns its value is not the
        !           879:      same as the one in which the caller sees the value.
        !           880: 
        !           881:      For such machines, `FUNCTION_VALUE' computes the register in which the
        !           882:      caller will see the value, and `FUNCTION_OUTGOING_VALUE' should be
        !           883:      defined in a similar fashion to tell the function where to put the
        !           884:      value.
        !           885: 
        !           886:      If `FUNCTION_OUTGOING_VALUE' is not defined, `FUNCTION_VALUE' serves
        !           887:      both purposes.
        !           888: 
        !           889: `LIBCALL_VALUE (MODE)'
        !           890:      A C expression to create an RTX representing the place where a library
        !           891:      function returns a value of mode MODE.  If the precise function being
        !           892:      called is known, FUNC is a tree node (`FUNCTION_DECL') for it;
        !           893:      otherwise, FUNC is a null pointer.  This makes it possible to use a
        !           894:      different value-returning convention for specific functions when all
        !           895:      their calls are known.
        !           896: 
        !           897:      Note that ``library function'' in this context means a compiler
        !           898:      support routine, used to perform arithmetic, whose name is known
        !           899:      specially by the compiler and was not mentioned in the C code being
        !           900:      compiled.
        !           901: 
        !           902: `FUNCTION_VALUE_REGNO_P (REGNO)'
        !           903:      A C expression that is nonzero if REGNO is the number of a hard
        !           904:      register in which function values are sometimes returned.
        !           905: 
        !           906:      A register whose use for returning values is limited to serving as the
        !           907:      second of a pair (for a value of type `double', say) need not be
        !           908:      recognized by this macro.  So for most machines, this definition
        !           909:      suffices:
        !           910: 
        !           911:           #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0)
        !           912: 
        !           913: 
        !           914: `FUNCTION_ARG (CUM, MODE, TYPE, NAMED)'
        !           915:      A C expression that controls whether a function argument is passed in
        !           916:      a register, and which register.
        !           917: 
        !           918:      The arguments are CUM, which summarizes all the previous arguments;
        !           919:      MODE, the machine mode of the argument; TYPE, the data type of the
        !           920:      argument as a tree node or 0 if that is not known (which happens for C
        !           921:      support library functions); and NAMED, which is 1 for an ordinary
        !           922:      argument and 0 for nameless arguments that correspond to `...' in the
        !           923:      called function's prototype.
        !           924: 
        !           925:      The value of the expression should either be a `reg' RTX for the hard
        !           926:      register in which to pass the argument, or zero to pass the argument
        !           927:      on the stack.
        !           928: 
        !           929:      For the Vax and 68000, where normally all arguments are pushed, zero
        !           930:      suffices as a definition.
        !           931: 
        !           932: `FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED)'
        !           933:      Define this macro if the target machine has ``register windows'', so
        !           934:      that the register in which a function sees an arguments is not
        !           935:      necessarily the same as the one in which the caller passed the argument.
        !           936: 
        !           937:      For such machines, `FUNCTION_ARG' computes the register in which the
        !           938:      caller passes the value, and `FUNCTION_INCOMING_ARG' should be defined
        !           939:      in a similar fashion to tell the function being called where the
        !           940:      arguments will arrive.
        !           941: 
        !           942:      If `FUNCTION_INCOMING_ARG' is not defined, `FUNCTION_ARG' serves both
        !           943:      purposes.
        !           944: 
        !           945: `FUNCTION_ARG_PARTIAL_NREGS (CUM, MODE, TYPE, NAMED)'
        !           946:      A C expression for the number of words, at the beginning of an
        !           947:      argument, must be put in registers.  The value must be zero for
        !           948:      arguments that are passed entirely in registers or that are entirely
        !           949:      pushed on the stack.
        !           950: 
        !           951:      On some machines, certain arguments must be passed partially in
        !           952:      registers and partially in memory.  On these machines, typically the
        !           953:      first N words of arguments are passed in registers, and the rest on
        !           954:      the stack.  If a multi-word argument (a `double' or a structure)
        !           955:      crosses that boundary, its first few words must be passed in registers
        !           956:      and the rest must be pushed.  This macro tells the compiler when this
        !           957:      occurs, and how many of the words should go in registers.
        !           958: 
        !           959:      `FUNCTION_ARG' for these arguments should return the first register to
        !           960:      be used by the caller for this argument; likewise
        !           961:      `FUNCTION_INCOMING_ARG', for the called function.
        !           962: 
        !           963: `CUMULATIVE_ARGS'
        !           964:      A C type for declaring a variable that is used as the first argument
        !           965:      of `FUNCTION_ARG' and other related values.  For some target machines,
        !           966:      the type `int' suffices and can hold the number of bytes of argument
        !           967:      so far.
        !           968: 
        !           969: `INIT_CUMULATIVE_ARGS (CUM)'
        !           970:      A C statement (sans semicolon) for initializing the variable CUM for
        !           971:      the state at the beginning of the argument list.  The variable has
        !           972:      type `CUMULATIVE_ARGS'.
        !           973: 
        !           974: `FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED)'
        !           975:      Update the summarizer variable CUM to advance past an argument in the
        !           976:      argument list.  The values MODE, TYPE and NAMED describe that
        !           977:      argument.  Once this is done, the variable CUM is suitable for
        !           978:      analyzing the *following* argument with `FUNCTION_ARG', etc.
        !           979: 
        !           980: `FUNCTION_ARG_REGNO_P (REGNO)'
        !           981:      A C expression that is nonzero if REGNO is the number of a hard
        !           982:      register in which function arguments are sometimes passed.  This does
        !           983:      *not* include implicit arguments such as the static chain and the
        !           984:      structure-value address.  On many machines, no registers can be used
        !           985:      for this purpose since all function arguments are pushed on the stack.
        !           986: 
        !           987: `FUNCTION_PROLOGUE (FILE, SIZE)'
        !           988:      A C compound statement that outputs the assembler code for entry to a
        !           989:      function.  The prologue is responsible for setting up the stack frame,
        !           990:      initializing the frame pointer register, saving registers that must be
        !           991:      saved, and allocating SIZE additional bytes of storage for the local
        !           992:      variables.  SIZE is an integer.  FILE is a stdio stream to which the
        !           993:      assembler code should be output.
        !           994: 
        !           995:      The label for the beginning of the function need not be output by this
        !           996:      macro.  That has already been done when the macro is run.
        !           997: 
        !           998:      To determine which registers to save, the macro can refer to the array
        !           999:      `regs_ever_live': element R is nonzero if hard register R is used
        !          1000:      anywhere within the function.  This implies the function prologue
        !          1001:      should save register R, but not if it is one of the call-used registers.
        !          1002: 
        !          1003:      On machines where functions may or may not have frame-pointers, the
        !          1004:      function entry code must vary accordingly; it must set up the frame
        !          1005:      pointer if one is wanted, and not otherwise.  To determine whether a
        !          1006:      frame pointer is in wanted, the macro can refer to the variable
        !          1007:      `frame_pointer_needed'.  The variable's value will be 1 at run time in
        !          1008:      a function that needs a frame pointer.
        !          1009: 
        !          1010: `FUNCTION_PROFILER (FILE, LABELNO)'
        !          1011:      A C statement or compound statement to output to FILE some assembler
        !          1012:      code to call the profiling subroutine `mcount'.  Before calling, the
        !          1013:      assembler code must load the address of a counter variable into a
        !          1014:      register where `mcount' expects to find the address.  The name of this
        !          1015:      variable is `LP' followed by the number LABELNO, so you would generate
        !          1016:      the name using `LP%d' in a `fprintf'.
        !          1017: 
        !          1018:      The details of how the address should be passed to `mcount' are
        !          1019:      determined by your operating system environment, not by GNU CC.  To
        !          1020:      figure them out, compile a small program for profiling using the
        !          1021:      system's installed C compiler and look at the assembler code that
        !          1022:      results.
        !          1023: 
        !          1024: `EXIT_IGNORES_STACK'
        !          1025:      Define this macro as a C expression that is nonzero if the return
        !          1026:      instruction or the function epilogue ignores the value of the stack
        !          1027:      pointer; in other words, if it is safe to delete an instruction to
        !          1028:      adjust the stack pointer before a return from the function.
        !          1029: 
        !          1030:      Note that this macro's value is relevant only for for which frame
        !          1031:      pointers are maintained.  It is never possible to delete a final stack
        !          1032:      adjustment in a function that has no frame pointer, and the compiler
        !          1033:      knows this regardless of `EXIT_IGNORES_STACK'.
        !          1034: 
        !          1035: `FUNCTION_EPILOGUE (FILE, SIZE)'
        !          1036:      A C compound statement that outputs the assembler code for exit from a
        !          1037:      function.  The epilogue is responsible for restoring the saved
        !          1038:      registers and stack pointer to their values when the function was
        !          1039:      called, and returning control to the caller.  This macro takes the
        !          1040:      same arguments as the macro `FUNCTION_PROLOGUE', and the registers to
        !          1041:      restore are determined from `regs_ever_live' and `CALL_USED_REGISTERS'
        !          1042:      in the same way.
        !          1043: 
        !          1044:      On some machines, there is a single instruction that does all the work
        !          1045:      of returning from the function.  On these machines, give that
        !          1046:      instruction the name `return' and do not define the macro
        !          1047:      `FUNCTION_EPILOGUE' at all.
        !          1048: 
        !          1049:      On machines where functions may or may not have frame-pointers, the
        !          1050:      function exit code must vary accordingly.  Sometimes the code for
        !          1051:      these two cases is completely different.  To determine whether a frame
        !          1052:      pointer is in wanted, the macro can refer to the variable
        !          1053:      `frame_pointer_needed'.  The variable's value will be 1 at run time in
        !          1054:      a function that needs a frame pointer.
        !          1055: 
        !          1056:      On some machines, some functions pop their arguments on exit while
        !          1057:      others leave that for the caller to do.  For example, the 68020 when
        !          1058:      given `-mrtd' pops arguments in functions that take a fixed number of
        !          1059:      arguments.
        !          1060: 
        !          1061:      Your definition of the macro `RETURN_POPS_ARGS' decides which
        !          1062:      functions pop their own arguments.  `FUNCTION_EPILOGUE' needs to know
        !          1063:      what was decided.  The variable `current_function_pops_args' is
        !          1064:      nonzero if the function should pop its own arguments.  If so, use the
        !          1065:      variable `current_function_args_size' as the number of bytes to pop.
        !          1066: 
        !          1067: `FIX_FRAME_POINTER_ADDRESS (ADDR, DEPTH)'
        !          1068:      A C compound statement to alter a memory address that uses the frame
        !          1069:      pointer register so that it uses the stack pointer register instead. 
        !          1070:      This must be done in the instructions that load parameter values into
        !          1071:      registers, when the reload pass determines that a frame pointer is not
        !          1072:      necessary for the function.  ADDR will be a C variable name, and the
        !          1073:      updated address should be stored in that variable.  DEPTH will be the
        !          1074:      current depth of stack temporaries (number of bytes of arguments
        !          1075:      currently pushed).  The change in offset between a
        !          1076:      frame-pointer-relative address and a stack-pointer-relative address
        !          1077:      must include DEPTH.
        !          1078: 
        !          1079:      Even if your machine description specifies there will always be a
        !          1080:      frame pointer in the frame pointer register, you must still define
        !          1081:      `FIX_FRAME_POINTER_ADDRESS', but the definition will never be executed
        !          1082:      at run time, so it may be empty.
        !          1083: 
        !          1084: 
        !          1085: File: internals,  Node: Library Names,  Next: Addressing Modes,  Prev: Stack Layout,  Up: Machine Macros
        !          1086: 
        !          1087: Library Subroutine Names
        !          1088: ========================
        !          1089: 
        !          1090: `UDIVSI3_LIBCALL'
        !          1091:      A C string constant giving the name of the function to call for
        !          1092:      division of a full-word by a full-word.  If you do not define this
        !          1093:      macro, the default name is used, which is `_udivsi3', a function
        !          1094:      defined in `gnulib'.
        !          1095: 
        !          1096: `UMODSI3_LIBCALL'
        !          1097:      A C string constant giving the name of the function to call for the
        !          1098:      remainder in division of a full-word by a full-word.  If you do not
        !          1099:      define this macro, the default name is used, which is `_umodsi3', a
        !          1100:      function defined in `gnulib'.
        !          1101: 
        !          1102: `TARGET_MEM_FUNCTIONS'
        !          1103:      Define this macro if GNU CC should generate calls to the System V (and
        !          1104:      ANSI C) library functions `memcpy' and `memset' rather than the BSD
        !          1105:      functions `bcopy' and `bzero'.
        !          1106: 
        !          1107: 
        !          1108: File: internals,  Node: Addressing Modes,  Next: Misc,  Prev: Library Names,  Up: Machine Macros
        !          1109: 
        !          1110: Addressing Modes
        !          1111: ================
        !          1112: 
        !          1113: `HAVE_POST_INCREMENT'
        !          1114:      Define this macro if the machine supports post-increment addressing.
        !          1115: 
        !          1116: `HAVE_PRE_INCREMENT'
        !          1117: `HAVE_POST_DECREMENT'
        !          1118: `HAVE_PRE_DECREMENT'
        !          1119:      Similar for other kinds of addressing.
        !          1120: 
        !          1121: `CONSTANT_ADDRESS_P (X)'
        !          1122:      A C expression that is 1 if the RTX X is a constant whose value is an
        !          1123:      integer.  This includes integers whose values are not explicitly
        !          1124:      known, such as `symbol_ref' and `label_ref' expressions and `const'
        !          1125:      arithmetic expressions.
        !          1126: 
        !          1127:      On most machines, this can be defined as `CONSTANT_P (X)', but a few
        !          1128:      machines are more restrictive in which constant addresses are supported.
        !          1129: 
        !          1130: `MAX_REGS_PER_ADDRESS'
        !          1131:      A number, the maximum number of registers that can appear in a valid
        !          1132:      memory address.
        !          1133: 
        !          1134: `GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL)'
        !          1135:      A C compound statement with a conditional `goto LABEL;' executed if X
        !          1136:      (an RTX) is a legitimate memory address on the target machine for a
        !          1137:      memory operand of mode MODE.
        !          1138: 
        !          1139:      It usually pays to define several simpler macros to serve as
        !          1140:      subroutines for this one.  Otherwise it may be too complicated to
        !          1141:      understand.
        !          1142: 
        !          1143:      This macro must exist in two variants: a strict variant and a
        !          1144:      non-strict one.  The strict variant is used in the reload pass.  It
        !          1145:      must be defined so that any pseudo-register that has not been
        !          1146:      allocated a hard register is considered a memory reference.  In
        !          1147:      contexts where some kind of register is required, a pseudo-register
        !          1148:      with no hard register must be rejected.
        !          1149: 
        !          1150:      The non-strict variant is used in other passes.  It must be defined to
        !          1151:      accept all pseudo-registers in every context where some kind of
        !          1152:      register is required.
        !          1153: 
        !          1154:      Compiler source files that want to use the strict variant of this
        !          1155:      macro define the macro `REG_OK_STRICT'.  You should use an `#ifdef
        !          1156:      REG_OK_STRICT' conditional to define the strict variant in that case
        !          1157:      and the non-strict variant otherwise.
        !          1158: 
        !          1159:      Typically among the subroutines used to define
        !          1160:      `GO_IF_LEGITIMATE_ADDRESS' are subroutines to check for acceptable
        !          1161:      registers for various purposes (one for base registers, one for index
        !          1162:      registers, and so on).  Then only these subroutine macros need have
        !          1163:      two variants; the higher levels of macros may be the same whether
        !          1164:      strict or not.
        !          1165: 
        !          1166: `LEGITIMIZE_ADDRESS (X, OLDX, MODE, WIN)'
        !          1167:      A C compound statement that attempts to replace X with a valid memory
        !          1168:      address for an operand of mode MODE.  WIN will be a C statement label
        !          1169:      elsewhere in the code; the macro definition may use
        !          1170: 
        !          1171:           GO_IF_LEGITIMATE_ADDRESS (MODE, X, WIN);
        !          1172: 
        !          1173: 
        !          1174:      to avoid further processing if the address has become legitimate.
        !          1175: 
        !          1176:      X will always be the result of a call to `break_out_memory_refs', and
        !          1177:      OLDX will be the operand that was given to that function to produce X.
        !          1178: 
        !          1179:      The code generated by this macro should not alter the substructure of
        !          1180:      X.  If it transforms X into a more legitimate form, it should assign X
        !          1181:      (which will always be a C variable) a new value.
        !          1182: 
        !          1183:      It is not necessary for this macro to come up with a legitimate
        !          1184:      address.  The compiler has standard ways of doing so in all cases.  In
        !          1185:      fact, it is safe for this macro to do nothing.  But often a
        !          1186:      machine-dependent strategy can generate better code.
        !          1187: 
        !          1188: `GO_IF_MODE_DEPENDENT_ADDRESS (ADDR, LABEL)'
        !          1189:      A C statement or compound statement with a conditional `goto LABEL;'
        !          1190:      executed if memory address X (an RTX) can have different meanings
        !          1191:      depending on the machine mode of the memory reference it is used for.
        !          1192: 
        !          1193:      Autoincrement and autodecrement addresses typically have
        !          1194:      mode-dependent effects because the amount of the increment or
        !          1195:      decrement is the size of the operand being addressed.  Some machines
        !          1196:      have other mode-dependent addresses.  Many RISC machines have no
        !          1197:      mode-dependent addresses.
        !          1198: 
        !          1199:      You may assume that ADDR is a valid address for the machine.
        !          1200: 
        !          1201: `LEGITIMATE_CONSTANT_P (X)'
        !          1202:      A C expression that is nonzero if X is a legitimate constant for an
        !          1203:      immediate operand on the target machine.  You can assume that either X
        !          1204:      is a `const_double' or it satisfies `CONSTANT_P', so you need not
        !          1205:      check these things.  In fact, `1' is a suitable definition for this
        !          1206:      macro on machines where any `const_double' is valid and anything
        !          1207:      `CONSTANT_P' is valid.
        !          1208: 
        !          1209: 

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.