Return to internals-5 CVS log

Up to [GCC 1.x] / gcc

Annotation of gcc/internals-5, revision 1.1.1.3

1.1.1.3 ! root        1: Info file internals, produced by Makeinfo, -*- Text -*- from input
        !             2: file internals.texinfo.
        !             3: 
        !             4: This file documents the internals of the GNU compiler.
        !             5: 
        !             6: Copyright (C) 1988 Free Software Foundation, Inc.
        !             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
        !            14: that the section entitled ``GNU CC General Public License'' is
        !            15: included exactly as in the original, and provided that the entire
        !            16: resulting derived work is distributed under the terms of a permission
        !            17: notice identical to this one.
        !            18: 
        !            19: Permission is granted to copy and distribute translations of this
        !            20: manual into another language, under the above conditions for modified
        !            21: versions, except that the section entitled ``GNU CC General Public
        !            22: License'' and this permission notice may be included in translations
        !            23: approved by the Free Software Foundation instead of in the original
        !            24: English.
        !            25: 
1.1       root       26: 
1.1.1.2   root       27: 
                     28: File: internals,  Node: Multi-Alternative,  Next: Class Preferences,  Prev: Simple Constraints,  Up: Constraints
                     29: 
                     30: Multiple Alternative Constraints
                     31: --------------------------------
                     32: 
1.1.1.3 ! root       33: Sometimes a single instruction has multiple alternative sets of
        !            34: possible operands.  For example, on the 68000, a logical-or
        !            35: instruction can combine register or an immediate value into memory,
        !            36: or it can combine any kind of operand into a register; but it cannot
        !            37: combine one memory location into another.
        !            38: 
        !            39: These constraints are represented as multiple alternatives.  An
        !            40: alternative can be described by a series of letters for each operand.
        !            41: The overall constraint for an operand is made from the letters for
        !            42: this operand from the first alternative, a comma, the letters for
        !            43: this operand from the second alternative, a comma, and so on until
        !            44: the last alternative.  Here is how it is done for fullword logical-or
        !            45: on the 68000:
1.1.1.2   root       46: 
                     47:      (define_insn "iorsi3"
                     48:        [(set (match_operand:SI 0 "general_operand" "=%m,d")
                     49:              (ior:SI (match_operand:SI 1 "general_operand" "0,0")
                     50:                      (match_operand:SI 2 "general_operand" "dKs,dmKs")))]
                     51:        ...)
                     52: 
1.1.1.3 ! root       53: The first alternative has `m' (memory) for operand 0, `0' for operand
        !            54: 1 (meaning it must match operand 0), and `dKs' for operand 2.  The
        !            55: second alternative has `d' (data register) for operand 0, `0' for
        !            56: operand 1, and `dmKs' for operand 2.  The `=' and `%' in the
        !            57: constraint for operand 0 are not part of any alternative; their
        !            58: meaning is explained in the next section.
        !            59: 
        !            60: If all the operands fit any one alternative, the instruction is valid.
        !            61: Otherwise, for each alternative, the compiler counts how many
        !            62: instructions must be added to copy the operands so that that
        !            63: alternative applies.  The alternative requiring the least copying is
        !            64: chosen.  If two alternatives need the same amount of copying, the one
        !            65: that comes first is chosen.  These choices can be altered with the
        !            66: `?' and `!' characters:
1.1.1.2   root       67: 
                     68: `?'
                     69:      Disparage slightly the alternative that the `?' appears in, as a
1.1.1.3 ! root       70:      choice when no alternative applies exactly.  The compiler
        !            71:      regards this alternative as one unit more costly for each `?'
        !            72:      that appears in it.
1.1.1.2   root       73: 
                     74: `!'
1.1.1.3 ! root       75:      Disparage severely the alternative that the `!' appears in. 
        !            76:      When operands must be copied into registers, the compiler will
        !            77:      never choose this alternative as the one to strive for.
        !            78: 
        !            79: When an insn pattern has multiple alternatives in its constraints,
        !            80: often the appearance of the assembler code determined mostly by which
        !            81: alternative was matched.  When this is so, the C code for writing the
        !            82: assembler code can use the variable `which_alternative', which is the
        !            83: ordinal number of the alternative that was actually satisfied (0 for
        !            84: the first, 1 for the second alternative, etc.).  For example:
1.1.1.2   root       85: 
                     86:      (define_insn ""
                     87:        [(set (match_operand:SI 0 "general_operand" "r,m")
                     88:              (const_int 0))]
                     89:        ""
                     90:        "*
                     91:        return (which_alternative == 0
                     92:                ? \"clrreg %0\" : \"clrmem %0\");
                     93:        ")
1.1       root       94: 
1.1.1.3 ! root       95: 
1.1.1.2   root       96: 
                     97: File: internals,  Node: Class Preferences,  Next: Modifiers,  Prev: Multi-Alternative,  Up: Constraints
                     98: 
                     99: Register Class Preferences
                    100: --------------------------
1.1       root      101: 
1.1.1.3 ! root      102: The operand constraints have another function: they enable the
        !           103: compiler to decide which kind of hardware register a pseudo register
        !           104: is best allocated to.  The compiler examines the constraints that
        !           105: apply to the insns that use the pseudo register, looking for the
        !           106: machine-dependent letters such as `d' and `a' that specify classes of
        !           107: registers.  The pseudo register is put in whichever class gets the
        !           108: most ``votes''.  The constraint letters `g' and `r' also vote: they
        !           109: vote in favor of a general register.  The machine description says
        !           110: which registers are considered general.
        !           111: 
        !           112: Of course, on some machines all registers are equivalent, and no
        !           113: register classes are defined.  Then none of this complexity is
        !           114: relevant.
1.1       root      115: 
                    116: 
1.1.1.2   root      117: 
                    118: File: internals,  Node: Modifiers,  Next: No Constraints,  Prev: Class Preferences,  Up: Constraints
1.1       root      119: 
1.1.1.2   root      120: Constraint Modifier Characters
                    121: ------------------------------
1.1       root      122: 
1.1.1.2   root      123: `='
                    124:      Means that this operand is write-only for this instruction: the
                    125:      previous value is discarded and replaced by output data.
                    126: 
                    127: `+'
1.1.1.3 ! root      128:      Means that this operand is both read and written by the
        !           129:      instruction.
1.1.1.2   root      130: 
1.1.1.3 ! root      131:      When the compiler fixes up the operands to satisfy the
        !           132:      constraints, it needs to know which operands are inputs to the
        !           133:      instruction and which are outputs from it.  `=' identifies an
        !           134:      output; `+' identifies an operand that is both input and output;
        !           135:      all other operands are assumed to be input only.
1.1.1.2   root      136: 
                    137: `&'
                    138:      Means (in a particular alternative) that this operand is written
                    139:      before the instruction is finished using the input operands. 
1.1.1.3 ! root      140:      Therefore, this operand may not lie in a register that is used
        !           141:      as an input operand or as part of any memory address.
1.1.1.2   root      142: 
                    143:      `&' applies only to the alternative in which it is written.  In
1.1.1.3 ! root      144:      constraints with multiple alternatives, sometimes one
        !           145:      alternative requires `&' while others do not.  See, for example,
        !           146:      the `movdf' insn of the 68000.
1.1.1.2   root      147: 
                    148:      `&' does not obviate the need to write `='.
                    149: 
                    150: `%'
1.1.1.3 ! root      151:      Declares the instruction to be commutative for this operand and
        !           152:      the following operand.  This means that the compiler may
        !           153:      interchange the two operands if that is the cheapest way to make
        !           154:      all operands fit the constraints.  This is often used in
        !           155:      patterns for addition instructions that really have only two
        !           156:      operands: the result must go in one of the arguments.  Here for
        !           157:      example, is how the 68000 halfword-add instruction is defined:
1.1.1.2   root      158: 
                    159:           (define_insn "addhi3"
                    160:             [(set (match_operand:HI 0 "general_operand" "=m,r")
                    161:                (plus:HI (match_operand:HI 1 "general_operand" "%0,0")
                    162:                         (match_operand:HI 2 "general_operand" "di,g")))]
                    163:             ...)
                    164: 
1.1.1.3 ! root      165:      Note that in previous versions of GNU CC the `%' constraint
        !           166:      modifier always applied to operands 1 and 2 regardless of which
        !           167:      operand it was written in.  The usual custom was to write it in
        !           168:      operand 0.  Now it must be in operand 1 if the operands to be
        !           169:      exchanged are 1 and 2.
1.1.1.2   root      170: 
                    171: `#'
1.1.1.3 ! root      172:      Says that all following characters, up to the next comma, are to
        !           173:      be ignored as a constraint.  They are significant only for
        !           174:      choosing register preferences.
1.1.1.2   root      175: 
                    176: `*'
1.1.1.3 ! root      177:      Says that the following character should be ignored when
        !           178:      choosing register preferences.  `*' has no effect on the meaning
        !           179:      of the constraint as a constraint.
        !           180: 
        !           181:      Here is an example: the 68000 has an instruction to sign-extend
        !           182:      a halfword in a data register, and can also sign-extend a value
        !           183:      by copying it into an address register.  While either kind of
        !           184:      register is acceptable, the constraints on an address-register
        !           185:      destination are less strict, so it is best if register
        !           186:      allocation makes an address register its goal.  Therefore, `*'
        !           187:      is used so that the `d' constraint letter (for data register) is
        !           188:      ignored when computing register preferences.
1.1.1.2   root      189: 
                    190:           (define_insn "extendhisi2"
                    191:             [(set (match_operand:SI 0 "general_operand" "=*d,a")
                    192:                   (sign_extend:SI
                    193:                    (match_operand:HI 1 "general_operand" "0,g")))]
                    194:             ...)
                    195: 
1.1.1.3 ! root      196: 
1.1.1.2   root      197: 
                    198: File: internals,  Node: No Constraints,  Prev: Modifiers,  Up: Constraints
1.1       root      199: 
1.1.1.2   root      200: Not Using Constraints
                    201: ---------------------
1.1       root      202: 
1.1.1.3 ! root      203: Some machines are so clean that operand constraints are not required.
        !           204: For example, on the Vax, an operand valid in one context is valid in
        !           205: any other context.  On such a machine, every operand constraint would
        !           206: be `g', excepting only operands of ``load address'' instructions
        !           207: which are written as if they referred to a memory location's contents
        !           208: but actual refer to its address.  They would have constraint `p'.
        !           209: 
        !           210: For such machines, instead of writing `g' and `p' for all the
        !           211: constraints, you can choose to write a description with empty
        !           212: constraints.  Then you write `""' for the constraint in every
        !           213: `match_operand'.  Address operands are identified by writing an
        !           214: `address' expression around the `match_operand', not by their
        !           215: constraints.
        !           216: 
        !           217: When the machine description has just empty constraints, certain
        !           218: parts of compilation are skipped, making the compiler faster.
1.1       root      219: 
1.1.1.2   root      220: 
                    221: 
                    222: File: internals,  Node: Standard Names,  Next: Pattern Ordering,  Prev: Constraints,  Up: Machine Desc
                    223: 
                    224: Standard Names for Patterns Used in Generation
                    225: ==============================================
                    226: 
1.1.1.3 ! root      227: Here is a table of the instruction names that are meaningful in the
        !           228: RTL generation pass of the compiler.  Giving one of these names to an
1.1.1.2   root      229: instruction pattern tells the RTL generation pass that it can use the
                    230: pattern in to accomplish a certain task.
                    231: 
                    232: `movM'
                    233:      Here M is a two-letter machine mode name, in lower case.  This
1.1.1.3 ! root      234:      instruction pattern moves data with that machine mode from
        !           235:      operand 1 to operand 0.  For example, `movsi' moves full-word
        !           236:      data.
        !           237: 
        !           238:      If operand 0 is a `subreg' with mode M of a register whose
        !           239:      natural mode is wider than M, the effect of this instruction is
        !           240:      to store the specified value in the part of the register that
        !           241:      corresponds to mode M.  The effect on the rest of the register
        !           242:      is undefined.
        !           243: 
        !           244:      This class of patterns is special in several ways.  First of
        !           245:      all, each of these names *must* be defined, because there is no
        !           246:      other way to copy a datum from one place to another.
        !           247: 
        !           248:      Second, these patterns are not used solely in the RTL generation
        !           249:      pass.  Even the reload pass can generate move insns to copy
        !           250:      values from stack slots into temporary registers.  When it does
        !           251:      so, one of the operands is a hard register and the other is an
        !           252:      operand that can have a reload.
1.1.1.2   root      253: 
                    254:      Therefore, when given such a pair of operands, the pattern must
1.1.1.3 ! root      255:      generate RTL which needs no temporary registers--no registers
        !           256:      other than the operands.  For example, if you support the
        !           257:      pattern with a `define_expand', then in such a case you mustn't
        !           258:      call `force_reg' or any other such function which might generate
        !           259:      new pseudo registers.
        !           260: 
        !           261:      This requirement exists even for subword modes on a RISC machine
        !           262:      where fetching those modes from memory normally requires several
        !           263:      insns and some temporary registers.  Look in `spur.md' to see
        !           264:      how the requirement is satisfied.
        !           265: 
        !           266:      The variety of operands that have reloads depends on the rest of
        !           267:      the machine description, but typically on a RISC machine these
        !           268:      can only be pseudo registers that did not get hard registers,
        !           269:      while on other machines explicit memory references will get
        !           270:      optional reloads.
        !           271: 
        !           272:      In addition, the constraints must allow any hard register to be
        !           273:      moved to any other hard register (provided that
        !           274:      `HARD_REGNO_MODE_OK' permits mode M in each of the registers).
1.1.1.2   root      275: 
                    276: `movstrictM'
1.1.1.3 ! root      277:      Like `movM' except that if operand 0 is a `subreg' with mode M
        !           278:      of a register whose natural mode is wider, the `movstrictM'
        !           279:      instruction is guaranteed not to alter any of the register
        !           280:      except the part which belongs to mode M.
1.1.1.2   root      281: 
                    282: `addM3'
1.1.1.3 ! root      283:      Add operand 2 and operand 1, storing the result in operand 0. 
        !           284:      All operands must have mode M.  This can be used even on
        !           285:      two-address machines, by means of constraints requiring operands
        !           286:      1 and 0 to be the same location.
1.1.1.2   root      287: 
                    288: `subM3', `mulM3', `umulM3', `divM3', `udivM3', `modM3', `umodM3', `andM3', `iorM3', `xorM3'
                    289:      Similar, for other arithmetic operations.
                    290: 
1.1.1.3 ! root      291:      There are special considerations for register classes for
        !           292:      logical-and instructions, affecting also the macro
        !           293:      `PREFERRED_RELOAD_CLASS'.  They apply not only to the patterns
        !           294:      with these standard names, but to any patterns that will match
        !           295:      such an instruction.  *Note Register Classes::.
        !           296: 
1.1.1.2   root      297: `andcbM3'
1.1.1.3 ! root      298:      Bitwise logical-and operand 1 with the complement of operand 2
        !           299:      and store the result in operand 0.
1.1.1.2   root      300: 
                    301: `mulhisi3'
                    302:      Multiply operands 1 and 2, which have mode `HImode', and store a
                    303:      `SImode' product in operand 0.
                    304: 
                    305: `mulqihi3', `mulsidi3'
                    306:      Similar widening-multiplication instructions of other widths.
                    307: 
                    308: `umulqihi3', `umulhisi3', `umulsidi3'
                    309:      Similar widening-multiplication instructions that do unsigned
                    310:      multiplication.
                    311: 
                    312: `divmodM4'
                    313:      Signed division that produces both a quotient and a remainder. 
1.1.1.3 ! root      314:      Operand 1 is divided by operand 2 to produce a quotient stored
        !           315:      in operand 0 and a remainder stored in operand 3.
1.1.1.2   root      316: 
                    317: `udivmodM4'
                    318:      Similar, but does unsigned division.
                    319: 
                    320: `divmodMN4'
1.1.1.3 ! root      321:      Like `divmodM4' except that only the dividend has mode M; the
        !           322:      divisor, quotient and remainder have mode N.  For example, the
        !           323:      Vax has a `divmoddisi4' instruction (but it is omitted from the
        !           324:      machine description, because it is so slow that it is faster to
        !           325:      compute remainders by the circumlocution that the compiler will
        !           326:      use if this instruction is not available).
1.1.1.2   root      327: 
                    328: `ashlM3'
                    329:      Arithmetic-shift operand 1 left by a number of bits specified by
1.1.1.3 ! root      330:      operand 2, and store the result in operand 0.  Operand 2 has
        !           331:      mode `SImode', not mode M.
1.1.1.2   root      332: 
                    333: `ashrM3', `lshlM3', `lshrM3', `rotlM3', `rotrM3'
                    334:      Other shift and rotate instructions.
                    335: 
1.1.1.3 ! root      336:      Logical and arithmetic left shift are the same.  Machines that
        !           337:      do not allow negative shift counts often have only one
        !           338:      instruction for shifting left.  On such machines, you should
        !           339:      define a pattern named `ashlM3' and leave `lshlM3' undefined.
        !           340: 
        !           341:      There are special considerations for register classes for shift
        !           342:      instructions, affecting also the macro `PREFERRED_RELOAD_CLASS'.
        !           343:      They apply not only to the patterns with these standard names,
        !           344:      but to any patterns that will match such an instruction.  *Note
        !           345:      Register Classes::.
1.1.1.2   root      346: 
                    347: `negM2'
                    348:      Negate operand 1 and store the result in operand 0.
                    349: 
                    350: `absM2'
                    351:      Store the absolute value of operand 1 into operand 0.
                    352: 
                    353: `sqrtM2'
                    354:      Store the square root of operand 1 into operand 0.
                    355: 
                    356: `ffsM2'
1.1.1.3 ! root      357:      Store into operand 0 one plus the index of the least significant
        !           358:      1-bit of operand 1.  If operand 1 is zero, store zero.  M is the
        !           359:      mode of operand 0; operand 1's mode is specified by the
        !           360:      instruction pattern, and the compiler will convert the operand
        !           361:      to that mode before generating the instruction.
1.1.1.2   root      362: 
                    363: `one_cmplM2'
                    364:      Store the bitwise-complement of operand 1 into operand 0.
                    365: 
                    366: `cmpM'
1.1.1.3 ! root      367:      Compare operand 0 and operand 1, and set the condition codes. 
        !           368:      The RTL pattern should look like this:
1.1.1.2   root      369: 
                    370:           (set (cc0) (minus (match_operand:M 0 ...)
                    371:                             (match_operand:M 1 ...)))
                    372: 
1.1.1.3 ! root      373:      Each such definition in the machine description, for integer
        !           374:      mode M, must have a corresponding `tstM' pattern, because
        !           375:      optimization can simplify the compare into a test when operand 1
        !           376:      is zero.
1.1.1.2   root      377: 
                    378: `tstM'
1.1.1.3 ! root      379:      Compare operand 0 against zero, and set the condition codes. 
        !           380:      The RTL pattern should look like this:
1.1.1.2   root      381: 
                    382:           (set (cc0) (match_operand:M 0 ...))
                    383: 
                    384: `movstrM'
1.1.1.3 ! root      385:      Block move instruction.  The addresses of the destination and
        !           386:      source strings are the first two operands, and both are in mode
        !           387:      `Pmode'.  The number of bytes to move is the third operand, in
        !           388:      mode M.
1.1.1.2   root      389: 
                    390: `cmpstrM'
1.1.1.3 ! root      391:      Block compare instruction, with operands like `movstrM' except
        !           392:      that the two memory blocks are compared byte by byte in
        !           393:      lexicographic order.  The effect of the instruction is to set
        !           394:      the condition codes.
1.1.1.2   root      395: 
                    396: `floatMN2'
1.1.1.3 ! root      397:      Convert operand 1 (valid for fixed point mode M) to floating
        !           398:      point mode N and store in operand 0 (which has mode N).
1.1.1.2   root      399: 
                    400: `fixMN2'
1.1.1.3 ! root      401:      Convert operand 1 (valid for floating point mode M) to fixed
        !           402:      point mode N as a signed number and store in operand 0 (which
        !           403:      has mode N).  This instruction's result is defined only when the
        !           404:      value of operand 1 is an integer.
1.1.1.2   root      405: 
                    406: `fixunsMN2'
1.1.1.3 ! root      407:      Convert operand 1 (valid for floating point mode M) to fixed
        !           408:      point mode N as an unsigned number and store in operand 0 (which
        !           409:      has mode N).  This instruction's result is defined only when the
        !           410:      value of operand 1 is an integer.
1.1.1.2   root      411: 
                    412: `ftruncM2'
1.1.1.3 ! root      413:      Convert operand 1 (valid for floating point mode M) to an
        !           414:      integer value, still represented in floating point mode M, and
        !           415:      store it in operand 0 (valid for floating point mode M).
1.1.1.2   root      416: 
                    417: `fix_truncMN2'
1.1.1.3 ! root      418:      Like `fixMN2' but works for any floating point value of mode M
        !           419:      by converting the value to an integer.
1.1.1.2   root      420: 
                    421: `fixuns_truncMN2'
1.1.1.3 ! root      422:      Like `fixunsMN2' but works for any floating point value of mode
        !           423:      M by converting the value to an integer.
1.1.1.2   root      424: 
                    425: `truncMN'
1.1.1.3 ! root      426:      Truncate operand 1 (valid for mode M) to mode N and store in
        !           427:      operand 0 (which has mode N).  Both modes must be fixed point or
        !           428:      both floating point.
1.1.1.2   root      429: 
                    430: `extendMN'
                    431:      Sign-extend operand 1 (valid for mode M) to mode N and store in
1.1.1.3 ! root      432:      operand 0 (which has mode N).  Both modes must be fixed point or
        !           433:      both floating point.
1.1.1.2   root      434: 
                    435: `zero_extendMN'
                    436:      Zero-extend operand 1 (valid for mode M) to mode N and store in
                    437:      operand 0 (which has mode N).  Both modes must be fixed point.
                    438: 
                    439: `extv'
1.1.1.3 ! root      440:      Extract a bit-field from operand 1 (a register or memory
        !           441:      operand), where operand 2 specifies the width in bits and
        !           442:      operand 3 the starting bit, and store it in operand 0.  Operand
        !           443:      0 must have `Simode'.  Operand 1 may have mode `QImode' or
        !           444:      `SImode'; often `SImode' is allowed only for registers. 
        !           445:      Operands 2 and 3 must be valid for `SImode'.
1.1.1.2   root      446: 
1.1.1.3 ! root      447:      The RTL generation pass generates this instruction only with
        !           448:      constants for operands 2 and 3.
1.1.1.2   root      449: 
1.1.1.3 ! root      450:      The bit-field value is sign-extended to a full word integer
        !           451:      before it is stored in operand 0.
1.1.1.2   root      452: 
                    453: `extzv'
                    454:      Like `extv' except that the bit-field value is zero-extended.
                    455: 
                    456: `insv'
1.1.1.3 ! root      457:      Store operand 3 (which must be valid for `SImode') into a
        !           458:      bit-field in operand 0, where operand 1 specifies the width in
        !           459:      bits and operand 2 the starting bit.  Operand 0 may have mode
        !           460:      `QImode' or `SImode'; often `SImode' is allowed only for
        !           461:      registers.  Operands 1 and 2 must be valid for `SImode'.
1.1.1.2   root      462: 
1.1.1.3 ! root      463:      The RTL generation pass generates this instruction only with
        !           464:      constants for operands 1 and 2.
1.1.1.2   root      465: 
                    466: `sCOND'
1.1.1.3 ! root      467:      Store zero or nonzero in the operand according to the condition
        !           468:      codes.  Value stored is nonzero iff the condition COND is true. 
        !           469:      COND is the name of a comparison operation expression code, such
        !           470:      as `eq', `lt' or `leu'.
        !           471: 
        !           472:      You specify the mode that the operand must have when you write
        !           473:      the `match_operand' expression.  The compiler automatically sees
        !           474:      which mode you have used and supplies an operand of that mode.
        !           475: 
        !           476:      The value stored for a true condition must have 1 as its low bit.
        !           477:      Otherwise the instruction is not suitable and must be omitted
        !           478:      from the machine description.  You must tell the compiler
        !           479:      exactly which value is stored by defining the macro
        !           480:      `STORE_FLAG_VALUE'.
1.1.1.2   root      481: 
                    482: `bCOND'
                    483:      Conditional branch instruction.  Operand 0 is a `label_ref' that
1.1.1.3 ! root      484:      refers to the label to jump to.  Jump if the condition codes
        !           485:      meet condition COND.
1.1.1.2   root      486: 
                    487: `call'
1.1.1.3 ! root      488:      Subroutine call instruction returning no value.  Operand 0 is
        !           489:      the function to call; operand 1 is the number of bytes of
        !           490:      arguments pushed (in mode `SImode', except it is normally a
        !           491:      `const_int'); operand 2 is the number of registers used as
        !           492:      operands.
        !           493: 
        !           494:      On most machines, operand 2 is not actually stored into the RTL
        !           495:      pattern.  It is supplied for the sake of some RISC machines
        !           496:      which need to put this information into the assembler code; they
        !           497:      can put it in the RTL instead of operand 1.
        !           498: 
        !           499:      Operand 0 should be a `mem' RTX whose address is the address of
1.1.1.2   root      500:      the function.
                    501: 
1.1.1.3 ! root      502: `call_value'
        !           503:      Subroutine call instruction returning a value.  Operand 0 is the
        !           504:      hard register in which the value is returned.  There are three
        !           505:      more operands, the same as the three operands of the `call'
        !           506:      instruction (but with numbers increased by one).
        !           507: 
        !           508:      Subroutines that return `BLKmode' objects use the `call' insn.
        !           509: 
1.1.1.2   root      510: `return'
1.1.1.3 ! root      511:      Subroutine return instruction.  This instruction pattern name
        !           512:      should be defined only if a single instruction can do all the
        !           513:      work of returning from a function.
1.1.1.2   root      514: 
                    515: `casesi'
1.1.1.3 ! root      516:      Instruction to jump through a dispatch table, including bounds
        !           517:      checking.  This instruction takes five operands:
1.1.1.2   root      518: 
                    519:        1. The index to dispatch on, which has mode `SImode'.
                    520: 
1.1.1.3 ! root      521:        2. The lower bound for indices in the table, an integer
        !           522:           constant.
1.1.1.2   root      523: 
1.1.1.3 ! root      524:        3. The upper bound for indices in the table, an integer
        !           525:           constant.
1.1.1.2   root      526: 
1.1.1.3 ! root      527:        4. A label to jump to if the index has a value outside the
        !           528:           bounds.  (If the machine-description macro
        !           529:           `CASE_DROPS_THROUGH' is defined, then an out-of-bounds
        !           530:           index drops through to the code following the jump table
        !           531:           instead of jumping to this label.  In that case, this label
        !           532:           is not actually used by the `casesi' instruction, but it is
1.1.1.2   root      533:           always provided as an operand.)
                    534: 
                    535:        5. A label that precedes the table itself.
                    536: 
1.1.1.3 ! root      537:      The table is a `addr_vec' or `addr_diff_vec' inside of a
        !           538:      `jump_insn'.  The number of elements in the table is one plus
        !           539:      the difference between the upper bound and the lower bound.
1.1.1.2   root      540: 
                    541: `tablejump'
                    542:      Instruction to jump to a variable address.  This is a low-level
1.1.1.3 ! root      543:      capability which can be used to implement a dispatch table when
        !           544:      there is no `casesi' pattern.
        !           545: 
        !           546:      This pattern requires two operands: the address or offset, and a
        !           547:      label which should immediately precede the jump table.  If the
        !           548:      macro `CASE_VECTOR_PC_RELATIVE' is defined then the first
        !           549:      operand is an absolute address to jump to; otherwise, it is an
        !           550:      offset which counts from the address of the table.
        !           551: 
        !           552:      The `tablejump' insn is always the last insn before the jump
        !           553:      table it uses.  Its assembler code normally has no need to use
        !           554:      the second operand, but you should incorporate it in the RTL
        !           555:      pattern so that the jump optimizer will not delete the table as
        !           556:      unreachable code.
1.1.1.2   root      557: 
                    558: 
                    559: 
                    560: File: internals,  Node: Pattern Ordering,  Next: Dependent Patterns,  Prev: Standard Names,  Up: Machine Desc
                    561: 
                    562: When the Order of Patterns Matters
                    563: ==================================
                    564: 
1.1.1.3 ! root      565: Sometimes an insn can match more than one instruction pattern.  Then
        !           566: the pattern that appears first in the machine description is the one
        !           567: used.  Therefore, more specific patterns (patterns that will match
        !           568: fewer things) and faster instructions (those that will produce better
        !           569: code when they do match) should usually go first in the description.
        !           570: 
        !           571: In some cases the effect of ordering the patterns can be used to hide
        !           572: a pattern when it is not valid.  For example, the 68000 has an
        !           573: instruction for converting a fullword to floating point and another
        !           574: for converting a byte to floating point.  An instruction converting
        !           575: an integer to floating point could match either one.  We put the
        !           576: pattern to convert the fullword first to make sure that one will be
        !           577: used rather than the other.  (Otherwise a large integer might be
        !           578: generated as a single-byte immediate quantity, which would not work.)
        !           579: Instead of using this pattern ordering it would be possible to make
        !           580: the pattern for convert-a-byte smart enough to deal properly with any
        !           581: constant value.
        !           582: 
1.1.1.2   root      583: 
                    584: 
                    585: File: internals,  Node: Dependent Patterns,  Next: Jump Patterns,  Prev: Pattern Ordering,  Up: Machine Desc
                    586: 
                    587: Interdependence of Patterns
                    588: ===========================
                    589: 
                    590: Every machine description must have a named pattern for each of the
1.1.1.3 ! root      591: conditional branch names `bCOND'.  The recognition template must
        !           592: always have the form
1.1.1.2   root      593: 
                    594:      (set (pc)
                    595:           (if_then_else (COND (cc0) (const_int 0))
                    596:                         (label_ref (match_operand 0 "" ""))
                    597:                         (pc)))
                    598: 
1.1.1.3 ! root      599: In addition, every machine description must have an anonymous pattern
        !           600: for each of the possible reverse-conditional branches.  These
        !           601: patterns look like
1.1.1.2   root      602: 
                    603:      (set (pc)
                    604:           (if_then_else (COND (cc0) (const_int 0))
                    605:                         (pc)
                    606:                         (label_ref (match_operand 0 "" ""))))
                    607: 
1.1.1.3 ! root      608: They are necessary because jump optimization can turn
        !           609: direct-conditional branches into reverse-conditional branches.
1.1.1.2   root      610: 
                    611: The compiler does more with RTL than just create it from patterns and
1.1.1.3 ! root      612: recognize the patterns: it can perform arithmetic expression codes
        !           613: when constant values for their operands can be determined.  As a
        !           614: result, sometimes having one pattern can require other patterns.  For
        !           615: example, the Vax has no `and' instruction, but it has `and not'
        !           616: instructions.  Here is the definition of one of them:
1.1.1.2   root      617: 
                    618:      (define_insn "andcbsi2"
                    619:        [(set (match_operand:SI 0 "general_operand" "")
                    620:              (and:SI (match_dup 0)
                    621:                      (not:SI (match_operand:SI
                    622:                                1 "general_operand" ""))))]
                    623:        ""
                    624:        "bicl2 %1,%0")
                    625: 
1.1.1.3 ! root      626: If operand 1 is an explicit integer constant, an instruction
        !           627: constructed using that pattern can be simplified into an `and' like
        !           628: this:
1.1.1.2   root      629: 
                    630:      (set (reg:SI 41)
                    631:           (and:SI (reg:SI 41)
                    632:                   (const_int 0xffff7fff)))
                    633: 
1.1.1.3 ! root      634: (where the integer constant is the one's complement of what appeared
        !           635: in the original instruction).
1.1.1.2   root      636: 
1.1.1.3 ! root      637: To avoid a fatal error, the compiler must have a pattern that
        !           638: recognizes such an instruction.  Here is what is used:
1.1.1.2   root      639: 
                    640:      (define_insn ""
                    641:        [(set (match_operand:SI 0 "general_operand" "")
                    642:              (and:SI (match_dup 0)
                    643:                      (match_operand:SI 1 "general_operand" "")))]
                    644:        "GET_CODE (operands[1]) == CONST_INT"
                    645:        "*
                    646:      { operands[1]
                    647:          = gen_rtx (CONST_INT, VOIDmode, ~INTVAL (operands[1]));
                    648:        return \"bicl2 %1,%0\";
                    649:      }")
                    650: 
1.1.1.3 ! root      651: Whereas a pattern to match a general `and' instruction is impossible
        !           652: to support on the Vax, this pattern is possible because it matches
        !           653: only a constant second argument: a special case that can be output as
        !           654: an `and not' instruction.
1.1.1.2   root      655: 
                    656: A ``compare'' instruction whose RTL looks like this:
                    657: 
                    658:      (set (cc0) (minus OPERAND (const_int 0)))
                    659: 
                    660: may be simplified by optimization into a ``test'' like this:
                    661: 
                    662:      (set (cc0) OPERAND)
                    663: 
1.1.1.3 ! root      664: So in the machine description, each ``compare'' pattern for an
        !           665: integer mode must have a corresponding ``test'' pattern that will
        !           666: match the result of such simplification.
1.1.1.2   root      667: 
                    668: In some cases machines support instructions identical except for the
                    669: machine mode of one or more operands.  For example, there may be
                    670: ``sign-extend halfword'' and ``sign-extend byte'' instructions whose
                    671: patterns are
                    672: 
                    673:      (set (match_operand:SI 0 ...)
                    674:           (extend:SI (match_operand:HI 1 ...)))
                    675:      
                    676:      (set (match_operand:SI 0 ...)
                    677:           (extend:SI (match_operand:QI 1 ...)))
                    678: 
                    679: Constant integers do not specify a machine mode, so an instruction to
                    680: extend a constant value could match either pattern.  The pattern it
1.1.1.3 ! root      681: actually will match is the one that appears first in the file.  For
        !           682: correct results, this must be the one for the widest possible mode
        !           683: (`HImode', here).  If the pattern matches the `QImode' instruction,
        !           684: the results will be incorrect if the constant value does not actually
        !           685: fit that mode.
        !           686: 
        !           687: Such instructions to extend constants are rarely generated because
        !           688: they are optimized away, but they do occasionally happen in
        !           689: nonoptimized compilations.
1.1.1.2   root      690: 
                    691: 
                    692: 
                    693: File: internals,  Node: Jump Patterns,  Next: Peephole Definitions,  Prev: Dependent Patterns,  Up: Machine Desc
                    694: 
                    695: Defining Jump Instruction Patterns
                    696: ==================================
                    697: 
1.1.1.3 ! root      698: GNU CC assumes that the machine has a condition code.  A comparison
        !           699: insn sets the condition code, recording the results of both signed
        !           700: and unsigned comparison of the given operands.  A separate branch
        !           701: insn tests the condition code and branches or not according its
        !           702: value.  The branch insns come in distinct signed and unsigned
        !           703: flavors.  Many common machines, such as the Vax, the 68000 and the
        !           704: 32000, work this way.
        !           705: 
        !           706: Some machines have distinct signed and unsigned compare instructions,
        !           707: and only one set of conditional branch instructions.  The easiest way
        !           708: to handle these machines is to treat them just like the others until
        !           709: the final stage where assembly code is written.  At this time, when
        !           710: outputting code for the compare instruction, peek ahead at the
        !           711: following branch using `NEXT_INSN (insn)'.  (The variable `insn'
        !           712: refers to the insn being output, in the output-writing code in an
        !           713: instruction pattern.)  If the RTL says that is an unsigned branch,
        !           714: output an unsigned compare; otherwise output a signed compare.  When
        !           715: the branch itself is output, you can treat signed and unsigned
        !           716: branches identically.
1.1.1.2   root      717: 
                    718: The reason you can do this is that GNU CC always generates a pair of
1.1.1.3 ! root      719: consecutive RTL insns, one to set the condition code and one to test
        !           720: it, and keeps the pair inviolate until the end.
        !           721: 
        !           722: To go with this technique, you must define the machine-description
        !           723: macro `NOTICE_UPDATE_CC' to do `CC_STATUS_INIT'; in other words, no
        !           724: compare instruction is superfluous.
        !           725: 
        !           726: Some machines have compare-and-branch instructions and no condition
        !           727: code.  A similar technique works for them.  When it is time to
        !           728: ``output'' a compare instruction, record its operands in two static
        !           729: variables.  When outputting the branch-on-condition-code instruction
        !           730: that follows, actually output a compare-and-branch instruction that
        !           731: uses the remembered operands.
        !           732: 
        !           733: It also works to define patterns for compare-and-branch instructions.
        !           734: In optimizing compilation, the pair of compare and branch
        !           735: instructions will be combined accoprding to these patterns.  But this
        !           736: does not happen if optimization is not requested.  So you must use
        !           737: one of the solutions above in addition to any special patterns you
        !           738: define.
1.1.1.2   root      739: 
1.1       root      740: 
                    741: 
                    742: File: internals,  Node: Peephole Definitions,  Next: Expander Definitions,  Prev: Jump Patterns,  Up: Machine Desc
                    743: 
                    744: Defining Machine-Specific Peephole Optimizers
                    745: =============================================
                    746: 
1.1.1.3 ! root      747: In addition to instruction patterns the `md' file may contain
        !           748: definitions of machine-specific peephole optimizations.
1.1       root      749: 
1.1.1.3 ! root      750: The combiner does not notice certain peephole optimizations when the
        !           751: data flow in the program does not suggest that it should try them. 
        !           752: For example, sometimes two consecutive insns related in purpose can
        !           753: be combined even though the second one does not appear to use a
        !           754: register computed in the first one.  A machine-specific peephole
        !           755: optimizer can detect such opportunities.
1.1       root      756: 
                    757: A definition looks like this:
                    758: 
                    759:      (define_peephole
                    760:        [INSN-PATTERN-1
                    761:         INSN-PATTERN-2
                    762:         ...]
                    763:        "CONDITION"
                    764:        "TEMPLATE")
                    765: 
                    766: In this skeleton, INSN-PATTERN-1 and so on are patterns to match
                    767: consecutive instructions.  The optimization applies to a sequence of
1.1.1.3 ! root      768: instructions when INSN-PATTERN-1 matches the first one,
        !           769: INSN-PATTERN-2 matches the next, and so on.
1.1       root      770: 
                    771: INSN-PATTERN-1 and so on look *almost* like the second operand of
1.1.1.3 ! root      772: `define_insn'.  There is one important difference: this pattern is an
        !           773: RTX, not a vector.  If the `define_insn' pattern would be a vector of
        !           774: one element, the INSN-PATTERN should be just that element, no vector.
        !           775: If the `define_insn' pattern would have multiple elements then the
        !           776: INSN-PATTERN must place the vector inside an explicit `parallel' RTX.
        !           777: 
        !           778: The operands of the instructions are matched with `match_operands'
        !           779: and `match_dup', as usual).  What is not usual is that the operand
        !           780: numbers apply to all the instruction patterns in the definition.  So,
        !           781: you can check for identical operands in two instructions by using
        !           782: `match_operand' in one instruction and `match_dup' in the other.
        !           783: 
        !           784: The operand constraints used in `match_operand' patterns do not have
        !           785: any direct effect on the applicability of the optimization, but they
        !           786: will be validated afterward, so write constraints that are sure to
        !           787: fit whenever the optimization is applied.  It is safe to use `"g"'
        !           788: for each operand.
        !           789: 
        !           790: Once a sequence of instructions matches the patterns, the CONDITION
        !           791: is checked.  This is a C expression which makes the final decision
        !           792: whether to perform the optimization (do so if the expression is
        !           793: nonzero).  If CONDITION is omitted (in other words, the string is
        !           794: empty) then the optimization is applied to every sequence of
        !           795: instructions that matches the patterns.
        !           796: 
        !           797: The defined peephole optimizations are applied after register
        !           798: allocation is complete.  Therefore, the optimizer can check which
        !           799: operands have ended up in which kinds of registers, just by looking
        !           800: at the operands.
        !           801: 
        !           802: The way to refer to the operands in CONDITION is to write
        !           803: `operands[I]' for operand number I (as matched by `(match_operand I
        !           804: ...)').  Use the variable `insn' to refer to the last of the insns
        !           805: being matched; use `PREV_INSN' to find the preceding insns (but be
        !           806: careful to skip over any `note' insns that intervene).
1.1       root      807: 
                    808: When optimizing computations with intermediate results, you can use
                    809: CONDITION to match only when the intermediate results are not used
1.1.1.3 ! root      810: elsewhere.  Use the C expression `dead_or_set_p (INSN, OP)', where
        !           811: INSN is the insn in which you expect the value to be used for the
        !           812: last time (from the value of `insn', together with use of
        !           813: `PREV_INSN'), and OP is the intermediate value (from `operands[I]').
        !           814: 
        !           815: Applying the optimization means replacing the sequence of
        !           816: instructions with one new instruction.  The TEMPLATE controls
        !           817: ultimate output of assembler code for this combined instruction.  It
        !           818: works exactly like the template of a `define_insn'.  Operand numbers
        !           819: in this template are the same ones used in matching the original
        !           820: sequence of instructions.
        !           821: 
        !           822: The result of a defined peephole optimizer does not need to match any
        !           823: of the instruction patterns, and it does not have an opportunity to
        !           824: match them.  The peephole optimizer definition itself serves as the
        !           825: instruction pattern to control how the instruction is output.
        !           826: 
        !           827: Defined peephole optimizers are run in the last jump optimization
        !           828: pass, so the instructions they produce are never combined or
        !           829: rearranged automatically in any way.
1.1       root      830: 
                    831: Here is an example, taken from the 68000 machine description:
                    832: 
                    833:      (define_peephole
                    834:        [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4)))
                    835:         (set (match_operand:DF 0 "register_operand" "f")
                    836:              (match_operand:DF 1 "register_operand" "ad"))]
                    837:        "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])"
                    838:        "*
                    839:      {
                    840:        rtx xoperands[2];
                    841:        xoperands[1] = gen_rtx (REG, SImode, REGNO (operands[1]) + 1);
                    842:      #ifdef MOTOROLA
                    843:        output_asm_insn (\"move.l %1,(sp)\", xoperands);
                    844:        output_asm_insn (\"move.l %1,-(sp)\", operands);
                    845:        return \"fmove.d (sp)+,%0\";
                    846:      #else
                    847:        output_asm_insn (\"movel %1,sp@\", xoperands);
                    848:        output_asm_insn (\"movel %1,sp@-\", operands);
                    849:        return \"fmoved sp@+,%0\";
                    850:      #endif
                    851:      }
                    852:      ")
                    853: 
                    854: The effect of this optimization is to change
                    855: 
                    856:      jbsr _foobar
                    857:      addql #4,sp
                    858:      movel d1,sp@-
                    859:      movel d0,sp@-
                    860:      fmoved sp@+,fp0
                    861: 
                    862: into
                    863: 
                    864:      jbsr _foobar
                    865:      movel d1,sp@
                    866:      movel d0,sp@-
                    867:      fmoved sp@+,fp0
                    868: 
1.1.1.3 ! root      869: 
1.1       root      870: 
                    871: File: internals,  Node: Expander Definitions,  Prev: Peephole Definitions,  Up: Machine Desc
                    872: 
                    873: Defining RTL Sequences for Code Generation
                    874: ==========================================
                    875: 
1.1.1.3 ! root      876: On some target machines, some standard pattern names for RTL
        !           877: generation cannot be handled with single insn, but a sequence of RTL
        !           878: insns can represent them.  For these target machines, you can write a
        !           879: `define_expand' to specify how to generate the sequence of RTL.
1.1       root      880: 
                    881: A `define_expand' is an RTL expression that looks almost like a
1.1.1.3 ! root      882: `define_insn'; but, unlike the latter, a `define_expand' is used only
        !           883: for RTL generation and it can produce more than one RTL insn.
1.1       root      884: 
                    885: A `define_expand' RTX has four operands:
                    886: 
1.1.1.3 ! root      887:    * The name.  Each `define_expand' must have a name, since the only
        !           888:      use for it is to refer to it by name.
1.1       root      889: 
                    890:    * The RTL template.  This is just like the RTL template for a
1.1.1.3 ! root      891:      `define_peephole' in that it is a vector of RTL expressions each
        !           892:      being one insn.
1.1       root      893: 
1.1.1.3 ! root      894:    * The condition, a string containing a C expression.  This
        !           895:      expression is used to express how the availability of this
        !           896:      pattern depends on subclasses of target machine, selected by
        !           897:      command-line options when GNU CC is run.  This is just like the
        !           898:      condition of a `define_insn' that has a standard name.
1.1       root      899: 
                    900:    * The preparation statements, a string containing zero or more C
1.1.1.3 ! root      901:      statements which are to be executed before RTL code is generated
        !           902:      from the RTL template.
1.1       root      903: 
                    904:      Usually these statements prepare temporary registers for use as
1.1.1.3 ! root      905:      internal operands in the RTL template, but they can also
        !           906:      generate RTL insns directly by calling routines such as
        !           907:      `emit_insn', etc.  Any such insns precede the ones that come
        !           908:      from the RTL template.
        !           909: 
        !           910: The RTL template, in addition to controlling generation of RTL insns,
        !           911: also describes the operands that need to be specified when this
        !           912: pattern is used.  In particular, it gives a predicate for each operand.
        !           913: 
        !           914: A true operand, which need to be specified in order to generate RTL
        !           915: from the pattern, should be described with a `match_operand' in its
        !           916: first occurrence in the RTL template.  This enters information on the
        !           917: operand's predicate into the tables that record such things.  GNU CC
        !           918: uses the information to preload the operand into a register if that
        !           919: is required for valid RTL code.  If the operand is referred to more
        !           920: than once, subsequent references should use `match_dup'.
1.1       root      921: 
                    922: The RTL template may also refer to internal ``operands'' which are
1.1.1.3 ! root      923: temporary registers or labels used only within the sequence made by
        !           924: the `define_expand'.  Internal operands are substituted into the RTL
        !           925: template with `match_dup', never with `match_operand'.  The values of
        !           926: the internal operands are not passed in as arguments by the compiler
        !           927: when it requests use of this pattern.  Instead, they are computed
        !           928: within the pattern, in the preparation statements.  These statements
        !           929: compute the values and store them into the appropriate elements of
        !           930: `operands' so that `match_dup' can find them.
        !           931: 
        !           932: There are two special macros defined for use in the preparation
        !           933: statements: `DONE' and `FAIL'.  Use them with a following semicolon,
        !           934: as a statement.
1.1       root      935: 
                    936: `DONE'
1.1.1.3 ! root      937:      Use the `DONE' macro to end RTL generation for the pattern.  The
        !           938:      only RTL insns resulting from the pattern on this occasion will
        !           939:      be those already emitted by explicit calls to `emit_insn' within
        !           940:      the preparation statements; the RTL template will not be
        !           941:      generated.
1.1       root      942: 
                    943: `FAIL'
1.1.1.3 ! root      944:      Make the pattern fail on this occasion.  When a pattern fails,
        !           945:      it means that the pattern was not truly available.  The calling
        !           946:      routines in the compiler will try other strategies for code
        !           947:      generation using other patterns.
1.1       root      948: 
1.1.1.3 ! root      949:      Failure is currently supported only for binary operations
        !           950:      (addition, multiplication, shifting, etc.).
1.1       root      951: 
                    952:      Do not emit any insns explicitly with `emit_insn' before failing.
                    953: 
                    954: Here is an example, the definition of left-shift for the SPUR chip:
                    955: 
                    956:      (define_expand "ashlsi3"
                    957:        [(set (match_operand:SI 0 "register_operand" "")
                    958:              (ashift:SI
                    959:                (match_operand:SI 1 "register_operand" "")
                    960:                (match_operand:SI 2 "nonmemory_operand" "")))]
                    961:        ""
                    962:        "
                    963:      {
                    964:        if (GET_CODE (operands[2]) != CONST_INT
                    965:            || (unsigned) INTVAL (operands[2]) > 3)
                    966:          FAIL;
                    967:      }")
                    968: 
1.1.1.3 ! root      969: This example uses `define_expand' so that it can generate an RTL insn
        !           970: for shifting when the shift-count is in the supported range of 0 to 3
        !           971: but fail in other cases where machine insns aren't available.  When
        !           972: it fails, the compiler tries another strategy using different
        !           973: patterns (such as, a library call).
1.1       root      974: 
                    975: If the compiler were able to handle nontrivial condition-strings in
1.1.1.3 ! root      976: patterns with names, then there would be possible to use a
        !           977: `define_insn' in that case.  Here is another case (zero-extension on
        !           978: the 68000) which makes more use of the power of `define_expand':
1.1       root      979: 
                    980:      (define_expand "zero_extendhisi2"
                    981:        [(set (match_operand:SI 0 "general_operand" "")
                    982:              (const_int 0))
                    983:         (set (strict_low_part 
                    984:                (subreg:HI
                    985:                  (match_operand:SI 0 "general_operand" "")
                    986:                  0))
                    987:              (match_operand:HI 1 "general_operand" ""))]
                    988:        ""
                    989:        "operands[1] = make_safe_from (operands[1], operands[0]);")
                    990: 
1.1.1.3 ! root      991: Here two RTL insns are generated, one to clear the entire output
        !           992: operand and the other to copy the input operand into its low half. 
        !           993: This sequence is incorrect if the input operand refers to [the old
        !           994: value of] the output operand, so the preparation statement makes sure
        !           995: this isn't so.  The function `make_safe_from' copies the
        !           996: `operands[1]' into a temporary register if it refers to
        !           997: `operands[0]'.  It does this by emitting another RTL insn.
1.1       root      998: 
                    999: Finally, a third example shows the use of an internal operand. 
1.1.1.3 ! root     1000: Zero-extension on the SPUR chip is done by `and'-ing the result
        !          1001: against a halfword mask.  But this mask cannot be represented by a
        !          1002: `const_int' because the constant value is too large to be legitimate
        !          1003: on this machine.  So it must be copied into a register with
        !          1004: `force_reg' and then the register used in the `and'.
1.1       root     1005: 
                   1006:      (define_expand "zero_extendhisi2"
                   1007:        [(set (match_operand:SI 0 "register_operand" "")
                   1008:              (and:SI (subreg:SI
                   1009:                        (match_operand:HI 1 "register_operand" "")
                   1010:                        0)
                   1011:                      (match_dup 2)))]
                   1012:        ""
                   1013:        "operands[2]
                   1014:           = force_reg (SImode, gen_rtx (CONST_INT,
                   1015:                                         VOIDmode, 65535)); ")
                   1016: 
1.1.1.3 ! root     1017: 
1.1       root     1018: 
                   1019: File: internals,  Node: Machine Macros,  Next: Config,  Prev: Machine Desc,  Up: Top
                   1020: 
                   1021: Machine Description Macros
                   1022: **************************
                   1023: 
1.1.1.3 ! root     1024: The other half of the machine description is a C header file
        !          1025: conventionally given the name `tm-MACHINE.h'.  The file `tm.h' should
        !          1026: be a link to it.  The header file `config.h' includes `tm.h' and most
        !          1027: compiler source files include `config.h'.
1.1       root     1028: 
                   1029: * Menu:
                   1030: 
                   1031: * Run-time Target::     Defining -m options like -m68000 and -m68020.
                   1032: * Storage Layout::      Defining sizes and alignments of data types.
                   1033: * Registers::           Naming and describing the hardware registers.
                   1034: * Register Classes::    Defining the classes of hardware registers.
                   1035: * Stack Layout::        Defining which way the stack grows and by how much.
                   1036: * Library Names::       Specifying names of subroutines to call automatically.
                   1037: * Addressing Modes::    Defining addressing modes valid for memory operands.
                   1038: * Condition Code::      Defining how insns update the condition code.
                   1039: * Assembler Format::    Defining how to write insns and pseudo-ops to output.
                   1040: * Misc::                Everything else.
                   1041: 
1.1.1.3 ! root     1042:  
1.1       root     1043: 
                   1044: File: internals,  Node: Run-time Target,  Next: Storage Layout,  Prev: Machine Macros,  Up: Machine Macros
                   1045: 
                   1046: Run-time Target Specification
                   1047: =============================
                   1048: 
                   1049: `CPP_PREDEFINES'
1.1.1.3 ! root     1050:      Define this to be a string constant containing `-D' options to
        !          1051:      define the predefined macros that identify this machine and
        !          1052:      system.  These macros will be predefined unless the `-ansi'
        !          1053:      option is specified.
1.1       root     1054: 
                   1055:      For example, on the Sun, one can use the value
                   1056: 
                   1057:           "-Dmc68000 -Dsun -Dunix"
                   1058: 
1.1.1.3 ! root     1059: `CPP_SPEC'
        !          1060:      A C string constant that tells the GNU CC driver program options
        !          1061:      to pass to CPP.  It can also specify how to translate options
        !          1062:      you give to GNU CC into options for GNU CC to pass to the CPP.
        !          1063: 
        !          1064:      Do not define this macro if it does not need to do anything.
        !          1065: 
        !          1066: `CC1_SPEC'
        !          1067:      A C string constant that tells the GNU CC driver program options
        !          1068:      to pass to CC1.  It can also specify how to translate options
        !          1069:      you give to GNU CC into options for GNU CC to pass to the CC1.
        !          1070: 
        !          1071:      Do not define this macro if it does not need to do anything.
        !          1072: 
1.1       root     1073: `extern int target_flags;'
                   1074:      This declaration should be present.
                   1075: 
                   1076: `TARGET_...'
1.1.1.3 ! root     1077:      This series of macros is to allow compiler command arguments to
        !          1078:      enable or disable the use of optional features of the target
        !          1079:      machine.  For example, one machine description serves both the
        !          1080:      68000 and the 68020; a command argument tells the compiler
        !          1081:      whether it should use 68020-only instructions or not.  This
        !          1082:      command argument works by means of a macro `TARGET_68020' that
        !          1083:      tests a bit in `target_flags'.
1.1       root     1084: 
                   1085:      Define a macro `TARGET_FEATURENAME' for each such option.  Its
                   1086:      definition should test a bit in `target_flags'; for example:
                   1087: 
                   1088:           #define TARGET_68020 (target_flags & 1)
                   1089: 
1.1.1.3 ! root     1090:      One place where these macros are used is in the
        !          1091:      condition-expressions of instruction patterns.  Note how
        !          1092:      `TARGET_68020' appears frequently in the 68000 machine
        !          1093:      description file, `m68k.md'.  Another place they are used is in
        !          1094:      the definitions of the other macros in the `tm-MACHINE.h' file.
1.1       root     1095: 
                   1096: `TARGET_SWITCHES'
1.1.1.3 ! root     1097:      This macro defines names of command options to set and clear
        !          1098:      bits in `target_flags'.  Its definition is an initializer with a
        !          1099:      subgrouping for each command option.
        !          1100: 
        !          1101:      Each subgrouping contains a string constant, that defines the
        !          1102:      option name, and a number, which contains the bits to set in
        !          1103:      `target_flags'.  A negative number says to clear bits instead;
        !          1104:      the negative of the number is which bits to clear.  The actual
        !          1105:      option name is made by appending `-m' to the specified name.
        !          1106: 
        !          1107:      One of the subgroupings should have a null string.  The number
        !          1108:      in this grouping is the default value for `target_flags'.  Any
        !          1109:      target options act starting with that value.
1.1       root     1110: 
1.1.1.3 ! root     1111:      Here is an example which defines `-m68000' and `-m68020' with
        !          1112:      opposite meanings, and picks the latter as the default:
1.1       root     1113: 
                   1114:           #define TARGET_SWITCHES \
                   1115:             { { "68020", 1},      \
                   1116:               { "68000", -1},     \
                   1117:               { "", 1}}
                   1118: 
1.1.1.3 ! root     1119: `OVERRIDE_OPTIONS'
        !          1120:      Sometimes certain combinations of command options do not make
        !          1121:      sense on a particular target machine.  You can define a macro
        !          1122:      `OVERRIDE_OPTIONS' to take account of this.  This macro, if
        !          1123:      defined, is executed once just after all the command options
        !          1124:      have been parsed.
        !          1125: 
1.1       root     1126: 
                   1127: 
                   1128: File: internals,  Node: Storage Layout,  Next: Registers,  Prev: Run-time Target,  Up: Machine Macros
                   1129: 
                   1130: Storage Layout
                   1131: ==============
                   1132: 
1.1.1.3 ! root     1133: Note that the definitions of the macros in this table which are sizes
        !          1134: or alignments measured in bits do not need to be constant.  They can
        !          1135: be C expressions that refer to static variables, such as the
        !          1136: `target_flags'.  *Note Run-time Target::.
1.1       root     1137: 
                   1138: `BITS_BIG_ENDIAN'
1.1.1.3 ! root     1139:      Define this macro if the most significant bit in a byte has the
        !          1140:      lowest number.  This means that bit-field instructions count
        !          1141:      from the most significant bit.  If the machine has no bit-field
        !          1142:      instructions, this macro is irrelevant.
1.1       root     1143: 
                   1144: `BYTES_BIG_ENDIAN'
                   1145:      Define this macro if the most significant byte in a word has the
                   1146:      lowest number.
                   1147: 
                   1148: `WORDS_BIG_ENDIAN'
1.1.1.3 ! root     1149:      Define this macro if, in a multiword object, the most
        !          1150:      significant word has the lowest number.
1.1       root     1151: 
                   1152: `BITS_PER_UNIT'
                   1153:      Number of bits in an addressable storage unit (byte); normally 8.
                   1154: 
                   1155: `BITS_PER_WORD'
                   1156:      Number of bits in a word; normally 32.
                   1157: 
                   1158: `UNITS_PER_WORD'
                   1159:      Number of storage units in a word; normally 4.
                   1160: 
                   1161: `POINTER_SIZE'
                   1162:      Width of a pointer, in bits.
                   1163: 
1.1.1.3 ! root     1164: `POINTER_BOUNDARY'
        !          1165:      Alignment required for pointers stored in memory, in bits.
        !          1166: 
1.1       root     1167: `PARM_BOUNDARY'
                   1168:      Alignment required for function parameters on the stack, in bits.
                   1169: 
                   1170: `STACK_BOUNDARY'
1.1.1.3 ! root     1171:      Define this macro if you wish to preserve a certain alignment
        !          1172:      for the stack pointer at all times.  The definition is a C
        !          1173:      expression for the desired alignment (measured in bits).
1.1       root     1174: 
                   1175: `FUNCTION_BOUNDARY'
                   1176:      Alignment required for a function entry point, in bits.
                   1177: 
                   1178: `BIGGEST_ALIGNMENT'
1.1.1.3 ! root     1179:      Biggest alignment that any data type can require on this
        !          1180:      machine, in bits.
1.1       root     1181: 
1.1.1.3 ! root     1182: `EMPTY_FIELD_BOUNDARY'
        !          1183:      Alignment in bits to be given to a structure bit field that
        !          1184:      follows an empty field such as `int : 0;'.
1.1       root     1185: 
                   1186: `STRUCTURE_SIZE_BOUNDARY'
1.1.1.3 ! root     1187:      Number of bits which any structure or union's size must be a
        !          1188:      multiple of.  Each structure or union's size is rounded up to a
        !          1189:      multiple of this.
1.1       root     1190: 
                   1191:      If you do not define this macro, the default is the same as
                   1192:      `BITS_PER_UNIT'.
                   1193: 
                   1194: `STRICT_ALIGNMENT'
1.1.1.3 ! root     1195:      Define this if instructions will fail to work if given data not
        !          1196:      on the nominal alignment.  If instructions will merely go slower
        !          1197:      in that case, do not define this macro.
        !          1198: 
        !          1199: `PCC_BITFIELD_TYPE_MATTERS'
        !          1200:      Define this if you wish to imitate a certain bizarre behavior
        !          1201:      pattern of some instances of PCC: a bit field whose declared
        !          1202:      type is `int' has the same effect on the size and alignment of a
        !          1203:      structure as an actual `int' would have.
        !          1204: 
        !          1205:      Just what effect that is in GNU CC depends on other parameters,
        !          1206:      but on most machines it would force the structure's alignment
        !          1207:      and size to a multiple of 32 or `BIGGEST_ALIGNMENT' bits.
        !          1208: 
        !          1209: `CHECK_FLOAT_VALUE (MODE, VALUE)'
        !          1210:      A C statement to validate the value VALUE (or type `double') for
        !          1211:      mode MODE.  This means that you check whether VALUE fits within
        !          1212:      the possible range of values for mode MODE on this target
        !          1213:      machine.  The mode MODE is always `SFmode' or `DFmode'.
        !          1214: 
        !          1215:      If VALUE is not valid, you should call `error' to print an error
        !          1216:      message and then assign some valid value to VALUE.  Allowing an
        !          1217:      invalid value to go through the compiler can produce incorrect
        !          1218:      assembler code which may even cause Unix assemblers to crash.
        !          1219: 
        !          1220:      This macro need not be defined if there is no work for it to do.
        !          1221: 
1.1       root     1222: 

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