Return to gcc.info-12 CVS log

Up to [Apple XNU] / GNUtools / cc

Annotation of GNUtools/cc/gcc.info-12, revision 1.1

1.1     ! root        1: This is Info file gcc.info, produced by Makeinfo-1.54 from the input
        !             2: file gcc.texi.
        !             3: 
        !             4:    This file documents the use and the internals of the GNU compiler.
        !             5: 
        !             6:    Published by the Free Software Foundation 675 Massachusetts Avenue
        !             7: Cambridge, MA 02139 USA
        !             8: 
        !             9:    Copyright (C) 1988, 1989, 1992, 1993 Free Software Foundation, Inc.
        !            10: 
        !            11:    Permission is granted to make and distribute verbatim copies of this
        !            12: manual provided the copyright notice and this permission notice are
        !            13: preserved on all copies.
        !            14: 
        !            15:    Permission is granted to copy and distribute modified versions of
        !            16: this manual under the conditions for verbatim copying, provided also
        !            17: that the sections entitled "GNU General Public License" and "Protect
        !            18: Your Freedom--Fight `Look And Feel'" are included exactly as in the
        !            19: original, and provided that the entire resulting derived work is
        !            20: distributed under the terms of a permission notice identical to this
        !            21: one.
        !            22: 
        !            23:    Permission is granted to copy and distribute translations of this
        !            24: manual into another language, under the above conditions for modified
        !            25: versions, except that the sections entitled "GNU General Public
        !            26: License" and "Protect Your Freedom--Fight `Look And Feel'", and this
        !            27: permission notice, may be included in translations approved by the Free
        !            28: Software Foundation instead of in the original English.
        !            29: 
        !            30: 
        !            31: File: gcc.info,  Node: Regs and Memory,  Next: Arithmetic,  Prev: Constants,  Up: RTL
        !            32: 
        !            33: Registers and Memory
        !            34: ====================
        !            35: 
        !            36:    Here are the RTL expression types for describing access to machine
        !            37: registers and to main memory.
        !            38: 
        !            39: `(reg:M N)'
        !            40:      For small values of the integer N (those that are less than
        !            41:      `FIRST_PSEUDO_REGISTER'), this stands for a reference to machine
        !            42:      register number N: a "hard register".  For larger values of N, it
        !            43:      stands for a temporary value or "pseudo register".  The compiler's
        !            44:      strategy is to generate code assuming an unlimited number of such
        !            45:      pseudo registers, and later convert them into hard registers or
        !            46:      into memory references.
        !            47: 
        !            48:      M is the machine mode of the reference.  It is necessary because
        !            49:      machines can generally refer to each register in more than one
        !            50:      mode.  For example, a register may contain a full word but there
        !            51:      may be instructions to refer to it as a half word or as a single
        !            52:      byte, as well as instructions to refer to it as a floating point
        !            53:      number of various precisions.
        !            54: 
        !            55:      Even for a register that the machine can access in only one mode,
        !            56:      the mode must always be specified.
        !            57: 
        !            58:      The symbol `FIRST_PSEUDO_REGISTER' is defined by the machine
        !            59:      description, since the number of hard registers on the machine is
        !            60:      an invariant characteristic of the machine.  Note, however, that
        !            61:      not all of the machine registers must be general registers.  All
        !            62:      the machine registers that can be used for storage of data are
        !            63:      given hard register numbers, even those that can be used only in
        !            64:      certain instructions or can hold only certain types of data.
        !            65: 
        !            66:      A hard register may be accessed in various modes throughout one
        !            67:      function, but each pseudo register is given a natural mode and is
        !            68:      accessed only in that mode.  When it is necessary to describe an
        !            69:      access to a pseudo register using a nonnatural mode, a `subreg'
        !            70:      expression is used.
        !            71: 
        !            72:      A `reg' expression with a machine mode that specifies more than
        !            73:      one word of data may actually stand for several consecutive
        !            74:      registers.  If in addition the register number specifies a
        !            75:      hardware register, then it actually represents several consecutive
        !            76:      hardware registers starting with the specified one.
        !            77: 
        !            78:      Each pseudo register number used in a function's RTL code is
        !            79:      represented by a unique `reg' expression.
        !            80: 
        !            81:      Some pseudo register numbers, those within the range of
        !            82:      `FIRST_VIRTUAL_REGISTER' to `LAST_VIRTUAL_REGISTER' only appear
        !            83:      during the RTL generation phase and are eliminated before the
        !            84:      optimization phases.  These represent locations in the stack frame
        !            85:      that cannot be determined until RTL generation for the function
        !            86:      has been completed.  The following virtual register numbers are
        !            87:      defined:
        !            88: 
        !            89:     `VIRTUAL_INCOMING_ARGS_REGNUM'
        !            90:           This points to the first word of the incoming arguments
        !            91:           passed on the stack.  Normally these arguments are placed
        !            92:           there by the caller, but the callee may have pushed some
        !            93:           arguments that were previously passed in registers.
        !            94: 
        !            95:           When RTL generation is complete, this virtual register is
        !            96:           replaced by the sum of the register given by
        !            97:           `ARG_POINTER_REGNUM' and the value of `FIRST_PARM_OFFSET'.
        !            98: 
        !            99:     `VIRTUAL_STACK_VARS_REGNUM'
        !           100:           If `FRAME_GROWS_DOWNWARD' is defined, this points to
        !           101:           immediately above the first variable on the stack.
        !           102:           Otherwise, it points to the first variable on the stack.
        !           103: 
        !           104:           `VIRTUAL_STACK_VARS_REGNUM' is replaced with the sum of the
        !           105:           register given by `FRAME_POINTER_REGNUM' and the value
        !           106:           `STARTING_FRAME_OFFSET'.
        !           107: 
        !           108:     `VIRTUAL_STACK_DYNAMIC_REGNUM'
        !           109:           This points to the location of dynamically allocated memory
        !           110:           on the stack immediately after the stack pointer has been
        !           111:           adjusted by the amount of memory desired.
        !           112: 
        !           113:           This virtual register is replaced by the sum of the register
        !           114:           given by `STACK_POINTER_REGNUM' and the value
        !           115:           `STACK_DYNAMIC_OFFSET'.
        !           116: 
        !           117:     `VIRTUAL_OUTGOING_ARGS_REGNUM'
        !           118:           This points to the location in the stack at which outgoing
        !           119:           arguments should be written when the stack is pre-pushed
        !           120:           (arguments pushed using push insns should always use
        !           121:           `STACK_POINTER_REGNUM').
        !           122: 
        !           123:           This virtual register is replaced by the sum of the register
        !           124:           given by `STACK_POINTER_REGNUM' and the value
        !           125:           `STACK_POINTER_OFFSET'.
        !           126: 
        !           127: `(subreg:M REG WORDNUM)'
        !           128:      `subreg' expressions are used to refer to a register in a machine
        !           129:      mode other than its natural one, or to refer to one register of a
        !           130:      multi-word `reg' that actually refers to several registers.
        !           131: 
        !           132:      Each pseudo-register has a natural mode.  If it is necessary to
        !           133:      operate on it in a different mode--for example, to perform a
        !           134:      fullword move instruction on a pseudo-register that contains a
        !           135:      single byte--the pseudo-register must be enclosed in a `subreg'.
        !           136:      In such a case, WORDNUM is zero.
        !           137: 
        !           138:      Usually M is at least as narrow as the mode of REG, in which case
        !           139:      it is restricting consideration to only the bits of REG that are
        !           140:      in M.
        !           141: 
        !           142:      Sometimes M is wider than the mode of REG.  These `subreg'
        !           143:      expressions are often called "paradoxical".  They are used in
        !           144:      cases where we want to refer to an object in a wider mode but do
        !           145:      not care what value the additional bits have.  The reload pass
        !           146:      ensures that paradoxical references are only made to hard
        !           147:      registers.
        !           148: 
        !           149:      The other use of `subreg' is to extract the individual registers of
        !           150:      a multi-register value.  Machine modes such as `DImode' and
        !           151:      `TImode' can indicate values longer than a word, values which
        !           152:      usually require two or more consecutive registers.  To access one
        !           153:      of the registers, use a `subreg' with mode `SImode' and a WORDNUM
        !           154:      that says which register.
        !           155: 
        !           156:      Storing in a non-paradoxical `subreg' has undefined results for
        !           157:      bits belonging to the same word as the `subreg'.  This laxity makes
        !           158:      it easier to generate efficient code for such instructions.  To
        !           159:      represent an instruction that preserves all the bits outside of
        !           160:      those in the `subreg', use `strict_low_part' around the `subreg'.
        !           161: 
        !           162:      The compilation parameter `WORDS_BIG_ENDIAN', if set to 1, says
        !           163:      that word number zero is the most significant part; otherwise, it
        !           164:      is the least significant part.
        !           165: 
        !           166:      Between the combiner pass and the reload pass, it is possible to
        !           167:      have a paradoxical `subreg' which contains a `mem' instead of a
        !           168:      `reg' as its first operand.  After the reload pass, it is also
        !           169:      possible to have a non-paradoxical `subreg' which contains a
        !           170:      `mem'; this usually occurs when the `mem' is a stack slot which
        !           171:      replaced a pseudo register.
        !           172: 
        !           173:      Note that it is not valid to access a `DFmode' value in `SFmode'
        !           174:      using a `subreg'.  On some machines the most significant part of a
        !           175:      `DFmode' value does not have the same format as a single-precision
        !           176:      floating value.
        !           177: 
        !           178:      It is also not valid to access a single word of a multi-word value
        !           179:      in a hard register when less registers can hold the value than
        !           180:      would be expected from its size.  For example, some 32-bit
        !           181:      machines have floating-point registers that can hold an entire
        !           182:      `DFmode' value.  If register 10 were such a register `(subreg:SI
        !           183:      (reg:DF 10) 1)' would be invalid because there is no way to
        !           184:      convert that reference to a single machine register.  The reload
        !           185:      pass prevents `subreg' expressions such as these from being formed.
        !           186: 
        !           187:      The first operand of a `subreg' expression is customarily accessed
        !           188:      with the `SUBREG_REG' macro and the second operand is customarily
        !           189:      accessed with the `SUBREG_WORD' macro.
        !           190: 
        !           191: `(scratch:M)'
        !           192:      This represents a scratch register that will be required for the
        !           193:      execution of a single instruction and not used subsequently.  It is
        !           194:      converted into a `reg' by either the local register allocator or
        !           195:      the reload pass.
        !           196: 
        !           197:      `scratch' is usually present inside a `clobber' operation (*note
        !           198:      Side Effects::.).
        !           199: 
        !           200: `(cc0)'
        !           201:      This refers to the machine's condition code register.  It has no
        !           202:      operands and may not have a machine mode.  There are two ways to
        !           203:      use it:
        !           204: 
        !           205:         * To stand for a complete set of condition code flags.  This is
        !           206:           best on most machines, where each comparison sets the entire
        !           207:           series of flags.
        !           208: 
        !           209:           With this technique, `(cc0)' may be validly used in only two
        !           210:           contexts: as the destination of an assignment (in test and
        !           211:           compare instructions) and in comparison operators comparing
        !           212:           against zero (`const_int' with value zero; that is to say,
        !           213:           `const0_rtx').
        !           214: 
        !           215:         * To stand for a single flag that is the result of a single
        !           216:           condition.  This is useful on machines that have only a
        !           217:           single flag bit, and in which comparison instructions must
        !           218:           specify the condition to test.
        !           219: 
        !           220:           With this technique, `(cc0)' may be validly used in only two
        !           221:           contexts: as the destination of an assignment (in test and
        !           222:           compare instructions) where the source is a comparison
        !           223:           operator, and as the first operand of `if_then_else' (in a
        !           224:           conditional branch).
        !           225: 
        !           226:      There is only one expression object of code `cc0'; it is the value
        !           227:      of the variable `cc0_rtx'.  Any attempt to create an expression of
        !           228:      code `cc0' will return `cc0_rtx'.
        !           229: 
        !           230:      Instructions can set the condition code implicitly.  On many
        !           231:      machines, nearly all instructions set the condition code based on
        !           232:      the value that they compute or store.  It is not necessary to
        !           233:      record these actions explicitly in the RTL because the machine
        !           234:      description includes a prescription for recognizing the
        !           235:      instructions that do so (by means of the macro
        !           236:      `NOTICE_UPDATE_CC').  *Note Condition Code::.  Only instructions
        !           237:      whose sole purpose is to set the condition code, and instructions
        !           238:      that use the condition code, need mention `(cc0)'.
        !           239: 
        !           240:      On some machines, the condition code register is given a register
        !           241:      number and a `reg' is used instead of `(cc0)'.  This is usually the
        !           242:      preferable approach if only a small subset of instructions modify
        !           243:      the condition code.  Other machines store condition codes in
        !           244:      general registers; in such cases a pseudo register should be used.
        !           245: 
        !           246:      Some machines, such as the Sparc and RS/6000, have two sets of
        !           247:      arithmetic instructions, one that sets and one that does not set
        !           248:      the condition code.  This is best handled by normally generating
        !           249:      the instruction that does not set the condition code, and making a
        !           250:      pattern that both performs the arithmetic and sets the condition
        !           251:      code register (which would not be `(cc0)' in this case).  For
        !           252:      examples, search for `addcc' and `andcc' in `sparc.md'.
        !           253: 
        !           254: `(pc)'
        !           255:      This represents the machine's program counter.  It has no operands
        !           256:      and may not have a machine mode.  `(pc)' may be validly used only
        !           257:      in certain specific contexts in jump instructions.
        !           258: 
        !           259:      There is only one expression object of code `pc'; it is the value
        !           260:      of the variable `pc_rtx'.  Any attempt to create an expression of
        !           261:      code `pc' will return `pc_rtx'.
        !           262: 
        !           263:      All instructions that do not jump alter the program counter
        !           264:      implicitly by incrementing it, but there is no need to mention
        !           265:      this in the RTL.
        !           266: 
        !           267: `(mem:M ADDR)'
        !           268:      This RTX represents a reference to main memory at an address
        !           269:      represented by the expression ADDR.  M specifies how large a unit
        !           270:      of memory is accessed.
        !           271: 
        !           272: 
        !           273: File: gcc.info,  Node: Arithmetic,  Next: Comparisons,  Prev: Regs and Memory,  Up: RTL
        !           274: 
        !           275: RTL Expressions for Arithmetic
        !           276: ==============================
        !           277: 
        !           278:    Unless otherwise specified, all the operands of arithmetic
        !           279: expressions must be valid for mode M.  An operand is valid for mode M
        !           280: if it has mode M, or if it is a `const_int' or `const_double' and M is
        !           281: a mode of class `MODE_INT'.
        !           282: 
        !           283:    For commutative binary operations, constants should be placed in the
        !           284: second operand.
        !           285: 
        !           286: `(plus:M X Y)'
        !           287:      Represents the sum of the values represented by X and Y carried
        !           288:      out in machine mode M.
        !           289: 
        !           290: `(lo_sum:M X Y)'
        !           291:      Like `plus', except that it represents that sum of X and the
        !           292:      low-order bits of Y.  The number of low order bits is
        !           293:      machine-dependent but is normally the number of bits in a `Pmode'
        !           294:      item minus the number of bits set by the `high' code (*note
        !           295:      Constants::.).
        !           296: 
        !           297:      M should be `Pmode'.
        !           298: 
        !           299: `(minus:M X Y)'
        !           300:      Like `plus' but represents subtraction.
        !           301: 
        !           302: `(compare:M X Y)'
        !           303:      Represents the result of subtracting Y from X for purposes of
        !           304:      comparison.  The result is computed without overflow, as if with
        !           305:      infinite precision.
        !           306: 
        !           307:      Of course, machines can't really subtract with infinite precision.
        !           308:      However, they can pretend to do so when only the sign of the
        !           309:      result will be used, which is the case when the result is stored
        !           310:      in the condition code.   And that is the only way this kind of
        !           311:      expression may validly be used: as a value to be stored in the
        !           312:      condition codes.
        !           313: 
        !           314:      The mode M is not related to the modes of X and Y, but instead is
        !           315:      the mode of the condition code value.  If `(cc0)' is used, it is
        !           316:      `VOIDmode'.  Otherwise it is some mode in class `MODE_CC', often
        !           317:      `CCmode'.  *Note Condition Code::.
        !           318: 
        !           319:      Normally, X and Y must have the same mode.  Otherwise, `compare'
        !           320:      is valid only if the mode of X is in class `MODE_INT' and Y is a
        !           321:      `const_int' or `const_double' with mode `VOIDmode'.  The mode of X
        !           322:      determines what mode the comparison is to be done in; thus it must
        !           323:      not be `VOIDmode'.
        !           324: 
        !           325:      If one of the operands is a constant, it should be placed in the
        !           326:      second operand and the comparison code adjusted as appropriate.
        !           327: 
        !           328:      A `compare' specifying two `VOIDmode' constants is not valid since
        !           329:      there is no way to know in what mode the comparison is to be
        !           330:      performed; the comparison must either be folded during the
        !           331:      compilation or the first operand must be loaded into a register
        !           332:      while its mode is still known.
        !           333: 
        !           334: `(neg:M X)'
        !           335:      Represents the negation (subtraction from zero) of the value
        !           336:      represented by X, carried out in mode M.
        !           337: 
        !           338: `(mult:M X Y)'
        !           339:      Represents the signed product of the values represented by X and Y
        !           340:      carried out in machine mode M.
        !           341: 
        !           342:      Some machines support a multiplication that generates a product
        !           343:      wider than the operands.  Write the pattern for this as
        !           344: 
        !           345:           (mult:M (sign_extend:M X) (sign_extend:M Y))
        !           346: 
        !           347:      where M is wider than the modes of X and Y, which need not be the
        !           348:      same.
        !           349: 
        !           350:      Write patterns for unsigned widening multiplication similarly using
        !           351:      `zero_extend'.
        !           352: 
        !           353: `(div:M X Y)'
        !           354:      Represents the quotient in signed division of X by Y, carried out
        !           355:      in machine mode M.  If M is a floating point mode, it represents
        !           356:      the exact quotient; otherwise, the integerized quotient.
        !           357: 
        !           358:      Some machines have division instructions in which the operands and
        !           359:      quotient widths are not all the same; you should represent such
        !           360:      instructions using `truncate' and `sign_extend' as in,
        !           361: 
        !           362:           (truncate:M1 (div:M2 X (sign_extend:M2 Y)))
        !           363: 
        !           364: `(udiv:M X Y)'
        !           365:      Like `div' but represents unsigned division.
        !           366: 
        !           367: `(mod:M X Y)'
        !           368: `(umod:M X Y)'
        !           369:      Like `div' and `udiv' but represent the remainder instead of the
        !           370:      quotient.
        !           371: 
        !           372: `(smin:M X Y)'
        !           373: `(smax:M X Y)'
        !           374:      Represents the smaller (for `smin') or larger (for `smax') of X
        !           375:      and Y, interpreted as signed integers in mode M.
        !           376: 
        !           377: `(umin:M X Y)'
        !           378: `(umax:M X Y)'
        !           379:      Like `smin' and `smax', but the values are interpreted as unsigned
        !           380:      integers.
        !           381: 
        !           382: `(not:M X)'
        !           383:      Represents the bitwise complement of the value represented by X,
        !           384:      carried out in mode M, which must be a fixed-point machine mode.
        !           385: 
        !           386: `(and:M X Y)'
        !           387:      Represents the bitwise logical-and of the values represented by X
        !           388:      and Y, carried out in machine mode M, which must be a fixed-point
        !           389:      machine mode.
        !           390: 
        !           391: `(ior:M X Y)'
        !           392:      Represents the bitwise inclusive-or of the values represented by X
        !           393:      and Y, carried out in machine mode M, which must be a fixed-point
        !           394:      mode.
        !           395: 
        !           396: `(xor:M X Y)'
        !           397:      Represents the bitwise exclusive-or of the values represented by X
        !           398:      and Y, carried out in machine mode M, which must be a fixed-point
        !           399:      mode.
        !           400: 
        !           401: `(ashift:M X C)'
        !           402:      Represents the result of arithmetically shifting X left by C
        !           403:      places.  X have mode M, a fixed-point machine mode.  C be a
        !           404:      fixed-point mode or be a constant with mode `VOIDmode'; which mode
        !           405:      is determined by the mode called for in the machine description
        !           406:      entry for the left-shift instruction.  For example, on the Vax,
        !           407:      the mode of C is `QImode' regardless of M.
        !           408: 
        !           409: `(lshift:M X C)'
        !           410:      Like `ashift' but for logical left shift.  `ashift' and `lshift'
        !           411:      are identical operations; we customarily use `ashift' for both.
        !           412: 
        !           413: `(lshiftrt:M X C)'
        !           414: `(ashiftrt:M X C)'
        !           415:      Like `lshift' and `ashift' but for right shift.  Unlike the case
        !           416:      for left shift, these two operations are distinct.
        !           417: 
        !           418: `(rotate:M X C)'
        !           419: `(rotatert:M X C)'
        !           420:      Similar but represent left and right rotate.  If C is a constant,
        !           421:      use `rotate'.
        !           422: 
        !           423: `(abs:M X)'
        !           424:      Represents the absolute value of X, computed in mode M.
        !           425: 
        !           426: `(sqrt:M X)'
        !           427:      Represents the square root of X, computed in mode M.  Most often M
        !           428:      will be a floating point mode.
        !           429: 
        !           430: `(ffs:M X)'
        !           431:      Represents one plus the index of the least significant 1-bit in X,
        !           432:      represented as an integer of mode M.  (The value is zero if X is
        !           433:      zero.)  The mode of X need not be M; depending on the target
        !           434:      machine, various mode combinations may be valid.
        !           435: 
        !           436: 
        !           437: File: gcc.info,  Node: Comparisons,  Next: Bit Fields,  Prev: Arithmetic,  Up: RTL
        !           438: 
        !           439: Comparison Operations
        !           440: =====================
        !           441: 
        !           442:    Comparison operators test a relation on two operands and are
        !           443: considered to represent a machine-dependent nonzero value described by,
        !           444: but not necessarily equal to, `STORE_FLAG_VALUE' (*note Misc::.) if the
        !           445: relation holds, or zero if it does not.  The mode of the comparison
        !           446: operation is independent of the mode of the data being compared.  If
        !           447: the comparison operation is being tested (e.g., the first operand of an
        !           448: `if_then_else'), the mode must be `VOIDmode'.  If the comparison
        !           449: operation is producing data to be stored in some variable, the mode
        !           450: must be in class `MODE_INT'.  All comparison operations producing data
        !           451: must use the same mode, which is machine-specific.
        !           452: 
        !           453:    There are two ways that comparison operations may be used.  The
        !           454: comparison operators may be used to compare the condition codes `(cc0)'
        !           455: against zero, as in `(eq (cc0) (const_int 0))'.  Such a construct
        !           456: actually refers to the result of the preceding instruction in which the
        !           457: condition codes were set.  The instructing setting the condition code
        !           458: must be adjacent to the instruction using the condition code; only
        !           459: `note' insns may separate them.
        !           460: 
        !           461:    Alternatively, a comparison operation may directly compare two data
        !           462: objects.  The mode of the comparison is determined by the operands; they
        !           463: must both be valid for a common machine mode.  A comparison with both
        !           464: operands constant would be invalid as the machine mode could not be
        !           465: deduced from it, but such a comparison should never exist in RTL due to
        !           466: constant folding.
        !           467: 
        !           468:    In the example above, if `(cc0)' were last set to `(compare X Y)',
        !           469: the comparison operation is identical to `(eq X Y)'.  Usually only one
        !           470: style of comparisons is supported on a particular machine, but the
        !           471: combine pass will try to merge the operations to produce the `eq' shown
        !           472: in case it exists in the context of the particular insn involved.
        !           473: 
        !           474:    Inequality comparisons come in two flavors, signed and unsigned.
        !           475: Thus, there are distinct expression codes `gt' and `gtu' for signed and
        !           476: unsigned greater-than.  These can produce different results for the same
        !           477: pair of integer values: for example, 1 is signed greater-than -1 but not
        !           478: unsigned greater-than, because -1 when regarded as unsigned is actually
        !           479: `0xffffffff' which is greater than 1.
        !           480: 
        !           481:    The signed comparisons are also used for floating point values.
        !           482: Floating point comparisons are distinguished by the machine modes of
        !           483: the operands.
        !           484: 
        !           485: `(eq:M X Y)'
        !           486:      1 if the values represented by X and Y are equal, otherwise 0.
        !           487: 
        !           488: `(ne:M X Y)'
        !           489:      1 if the values represented by X and Y are not equal, otherwise 0.
        !           490: 
        !           491: `(gt:M X Y)'
        !           492:      1 if the X is greater than Y.  If they are fixed-point, the
        !           493:      comparison is done in a signed sense.
        !           494: 
        !           495: `(gtu:M X Y)'
        !           496:      Like `gt' but does unsigned comparison, on fixed-point numbers
        !           497:      only.
        !           498: 
        !           499: `(lt:M X Y)'
        !           500: `(ltu:M X Y)'
        !           501:      Like `gt' and `gtu' but test for "less than".
        !           502: 
        !           503: `(ge:M X Y)'
        !           504: `(geu:M X Y)'
        !           505:      Like `gt' and `gtu' but test for "greater than or equal".
        !           506: 
        !           507: `(le:M X Y)'
        !           508: `(leu:M X Y)'
        !           509:      Like `gt' and `gtu' but test for "less than or equal".
        !           510: 
        !           511: `(if_then_else COND THEN ELSE)'
        !           512:      This is not a comparison operation but is listed here because it is
        !           513:      always used in conjunction with a comparison operation.  To be
        !           514:      precise, COND is a comparison expression.  This expression
        !           515:      represents a choice, according to COND, between the value
        !           516:      represented by THEN and the one represented by ELSE.
        !           517: 
        !           518:      On most machines, `if_then_else' expressions are valid only to
        !           519:      express conditional jumps.
        !           520: 
        !           521: `(cond [TEST1 VALUE1 TEST2 VALUE2 ...] DEFAULT)'
        !           522:      Similar to `if_then_else', but more general.  Each of TEST1,
        !           523:      TEST2, ... is performed in turn.  The result of this expression is
        !           524:      the VALUE corresponding to the first non-zero test, or DEFAULT if
        !           525:      none of the tests are non-zero expressions.
        !           526: 
        !           527:      This is currently not valid for instruction patterns and is
        !           528:      supported only for insn attributes.  *Note Insn Attributes::.
        !           529: 
        !           530: 
        !           531: File: gcc.info,  Node: Bit Fields,  Next: Conversions,  Prev: Comparisons,  Up: RTL
        !           532: 
        !           533: Bit Fields
        !           534: ==========
        !           535: 
        !           536:    Special expression codes exist to represent bitfield instructions.
        !           537: These types of expressions are lvalues in RTL; they may appear on the
        !           538: left side of an assignment, indicating insertion of a value into the
        !           539: specified bit field.
        !           540: 
        !           541: `(sign_extract:M LOC SIZE POS)'
        !           542:      This represents a reference to a sign-extended bit field contained
        !           543:      or starting in LOC (a memory or register reference).  The bit field
        !           544:      is SIZE bits wide and starts at bit POS.  The compilation option
        !           545:      `BITS_BIG_ENDIAN' says which end of the memory unit POS counts
        !           546:      from.
        !           547: 
        !           548:      If LOC is in memory, its mode must be a single-byte integer mode.
        !           549:      If LOC is in a register, the mode to use is specified by the
        !           550:      operand of the `insv' or `extv' pattern (*note Standard Names::.)
        !           551:      and is usually a full-word integer mode.
        !           552: 
        !           553:      The mode of POS is machine-specific and is also specified in the
        !           554:      `insv' or `extv' pattern.
        !           555: 
        !           556:      The mode M is the same as the mode that would be used for LOC if
        !           557:      it were a register.
        !           558: 
        !           559: `(zero_extract:M LOC SIZE POS)'
        !           560:      Like `sign_extract' but refers to an unsigned or zero-extended bit
        !           561:      field.  The same sequence of bits are extracted, but they are
        !           562:      filled to an entire word with zeros instead of by sign-extension.
        !           563: 
        !           564: 
        !           565: File: gcc.info,  Node: Conversions,  Next: RTL Declarations,  Prev: Bit Fields,  Up: RTL
        !           566: 
        !           567: Conversions
        !           568: ===========
        !           569: 
        !           570:    All conversions between machine modes must be represented by
        !           571: explicit conversion operations.  For example, an expression which is
        !           572: the sum of a byte and a full word cannot be written as `(plus:SI
        !           573: (reg:QI 34) (reg:SI 80))' because the `plus' operation requires two
        !           574: operands of the same machine mode.  Therefore, the byte-sized operand
        !           575: is enclosed in a conversion operation, as in
        !           576: 
        !           577:      (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80))
        !           578: 
        !           579:    The conversion operation is not a mere placeholder, because there
        !           580: may be more than one way of converting from a given starting mode to
        !           581: the desired final mode.  The conversion operation code says how to do
        !           582: it.
        !           583: 
        !           584:    For all conversion operations, X must not be `VOIDmode' because the
        !           585: mode in which to do the conversion would not be known.  The conversion
        !           586: must either be done at compile-time or X must be placed into a register.
        !           587: 
        !           588: `(sign_extend:M X)'
        !           589:      Represents the result of sign-extending the value X to machine
        !           590:      mode M.  M must be a fixed-point mode and X a fixed-point value of
        !           591:      a mode narrower than M.
        !           592: 
        !           593: `(zero_extend:M X)'
        !           594:      Represents the result of zero-extending the value X to machine
        !           595:      mode M.  M must be a fixed-point mode and X a fixed-point value of
        !           596:      a mode narrower than M.
        !           597: 
        !           598: `(float_extend:M X)'
        !           599:      Represents the result of extending the value X to machine mode M.
        !           600:      m must be a floating point mode and X a floating point value of a
        !           601:      mode narrower than M.
        !           602: 
        !           603: `(truncate:M X)'
        !           604:      Represents the result of truncating the value X to machine mode M.
        !           605:      M must be a fixed-point mode and X a fixed-point value of a mode
        !           606:      wider than M.
        !           607: 
        !           608: `(float_truncate:M X)'
        !           609:      Represents the result of truncating the value X to machine mode M.
        !           610:      M must be a floating point mode and X a floating point value of a
        !           611:      mode wider than M.
        !           612: 
        !           613: `(float:M X)'
        !           614:      Represents the result of converting fixed point value X, regarded
        !           615:      as signed, to floating point mode M.
        !           616: 
        !           617: `(unsigned_float:M X)'
        !           618:      Represents the result of converting fixed point value X, regarded
        !           619:      as unsigned, to floating point mode M.
        !           620: 
        !           621: `(fix:M X)'
        !           622:      When M is a fixed point mode, represents the result of converting
        !           623:      floating point value X to mode M, regarded as signed.  How
        !           624:      rounding is done is not specified, so this operation may be used
        !           625:      validly in compiling C code only for integer-valued operands.
        !           626: 
        !           627: `(unsigned_fix:M X)'
        !           628:      Represents the result of converting floating point value X to
        !           629:      fixed point mode M, regarded as unsigned.  How rounding is done is
        !           630:      not specified.
        !           631: 
        !           632: `(fix:M X)'
        !           633:      When M is a floating point mode, represents the result of
        !           634:      converting floating point value X (valid for mode M) to an
        !           635:      integer, still represented in floating point mode M, by rounding
        !           636:      towards zero.
        !           637: 
        !           638: 
        !           639: File: gcc.info,  Node: RTL Declarations,  Next: Side Effects,  Prev: Conversions,  Up: RTL
        !           640: 
        !           641: Declarations
        !           642: ============
        !           643: 
        !           644:    Declaration expression codes do not represent arithmetic operations
        !           645: but rather state assertions about their operands.
        !           646: 
        !           647: `(strict_low_part (subreg:M (reg:N R) 0))'
        !           648:      This expression code is used in only one context: as the
        !           649:      destination operand of a `set' expression.  In addition, the
        !           650:      operand of this expression must be a non-paradoxical `subreg'
        !           651:      expression.
        !           652: 
        !           653:      The presence of `strict_low_part' says that the part of the
        !           654:      register which is meaningful in mode N, but is not part of mode M,
        !           655:      is not to be altered.  Normally, an assignment to such a subreg is
        !           656:      allowed to have undefined effects on the rest of the register when
        !           657:      M is less than a word.
        !           658: 
        !           659: 
        !           660: File: gcc.info,  Node: Side Effects,  Next: Incdec,  Prev: RTL Declarations,  Up: RTL
        !           661: 
        !           662: Side Effect Expressions
        !           663: =======================
        !           664: 
        !           665:    The expression codes described so far represent values, not actions.
        !           666: But machine instructions never produce values; they are meaningful only
        !           667: for their side effects on the state of the machine.  Special expression
        !           668: codes are used to represent side effects.
        !           669: 
        !           670:    The body of an instruction is always one of these side effect codes;
        !           671: the codes described above, which represent values, appear only as the
        !           672: operands of these.
        !           673: 
        !           674: `(set LVAL X)'
        !           675:      Represents the action of storing the value of X into the place
        !           676:      represented by LVAL.  LVAL must be an expression representing a
        !           677:      place that can be stored in: `reg' (or `subreg' or
        !           678:      `strict_low_part'), `mem', `pc' or `cc0'.
        !           679: 
        !           680:      If LVAL is a `reg', `subreg' or `mem', it has a machine mode; then
        !           681:      X must be valid for that mode.
        !           682: 
        !           683:      If LVAL is a `reg' whose machine mode is less than the full width
        !           684:      of the register, then it means that the part of the register
        !           685:      specified by the machine mode is given the specified value and the
        !           686:      rest of the register receives an undefined value.  Likewise, if
        !           687:      LVAL is a `subreg' whose machine mode is narrower than the mode of
        !           688:      the register, the rest of the register can be changed in an
        !           689:      undefined way.
        !           690: 
        !           691:      If LVAL is a `strict_low_part' of a `subreg', then the part of the
        !           692:      register specified by the machine mode of the `subreg' is given
        !           693:      the value X and the rest of the register is not changed.
        !           694: 
        !           695:      If LVAL is `(cc0)', it has no machine mode, and X may be either a
        !           696:      `compare' expression or a value that may have any mode.  The
        !           697:      latter case represents a "test" instruction.  The expression `(set
        !           698:      (cc0) (reg:M N))' is equivalent to `(set (cc0) (compare (reg:M N)
        !           699:      (const_int 0)))'.  Use the former expression to save space during
        !           700:      the compilation.
        !           701: 
        !           702:      If LVAL is `(pc)', we have a jump instruction, and the
        !           703:      possibilities for X are very limited.  It may be a `label_ref'
        !           704:      expression (unconditional jump).  It may be an `if_then_else'
        !           705:      (conditional jump), in which case either the second or the third
        !           706:      operand must be `(pc)' (for the case which does not jump) and the
        !           707:      other of the two must be a `label_ref' (for the case which does
        !           708:      jump).  X may also be a `mem' or `(plus:SI (pc) Y)', where Y may
        !           709:      be a `reg' or a `mem'; these unusual patterns are used to
        !           710:      represent jumps through branch tables.
        !           711: 
        !           712:      If LVAL is neither `(cc0)' nor `(pc)', the mode of LVAL must not
        !           713:      be `VOIDmode' and the mode of X must be valid for the mode of LVAL.
        !           714: 
        !           715:      LVAL is customarily accessed with the `SET_DEST' macro and X with
        !           716:      the `SET_SRC' macro.
        !           717: 
        !           718: `(return)'
        !           719:      As the sole expression in a pattern, represents a return from the
        !           720:      current function, on machines where this can be done with one
        !           721:      instruction, such as Vaxes.  On machines where a multi-instruction
        !           722:      "epilogue" must be executed in order to return from the function,
        !           723:      returning is done by jumping to a label which precedes the
        !           724:      epilogue, and the `return' expression code is never used.
        !           725: 
        !           726:      Inside an `if_then_else' expression, represents the value to be
        !           727:      placed in `pc' to return to the caller.
        !           728: 
        !           729:      Note that an insn pattern of `(return)' is logically equivalent to
        !           730:      `(set (pc) (return))', but the latter form is never used.
        !           731: 
        !           732: `(call FUNCTION NARGS)'
        !           733:      Represents a function call.  FUNCTION is a `mem' expression whose
        !           734:      address is the address of the function to be called.  NARGS is an
        !           735:      expression which can be used for two purposes: on some machines it
        !           736:      represents the number of bytes of stack argument; on others, it
        !           737:      represents the number of argument registers.
        !           738: 
        !           739:      Each machine has a standard machine mode which FUNCTION must have.
        !           740:      The machine description defines macro `FUNCTION_MODE' to expand
        !           741:      into the requisite mode name.  The purpose of this mode is to
        !           742:      specify what kind of addressing is allowed, on machines where the
        !           743:      allowed kinds of addressing depend on the machine mode being
        !           744:      addressed.
        !           745: 
        !           746: `(clobber X)'
        !           747:      Represents the storing or possible storing of an unpredictable,
        !           748:      undescribed value into X, which must be a `reg', `scratch' or
        !           749:      `mem' expression.
        !           750: 
        !           751:      One place this is used is in string instructions that store
        !           752:      standard values into particular hard registers.  It may not be
        !           753:      worth the trouble to describe the values that are stored, but it
        !           754:      is essential to inform the compiler that the registers will be
        !           755:      altered, lest it attempt to keep data in them across the string
        !           756:      instruction.
        !           757: 
        !           758:      If X is `(mem:BLK (const_int 0))', it means that all memory
        !           759:      locations must be presumed clobbered.
        !           760: 
        !           761:      Note that the machine description classifies certain hard
        !           762:      registers as "call-clobbered".  All function call instructions are
        !           763:      assumed by default to clobber these registers, so there is no need
        !           764:      to use `clobber' expressions to indicate this fact.  Also, each
        !           765:      function call is assumed to have the potential to alter any memory
        !           766:      location, unless the function is declared `const'.
        !           767: 
        !           768:      If the last group of expressions in a `parallel' are each a
        !           769:      `clobber' expression whose arguments are `reg' or `match_scratch'
        !           770:      (*note RTL Template::.) expressions, the combiner phase can add
        !           771:      the appropriate `clobber' expressions to an insn it has
        !           772:      constructed when doing so will cause a pattern to be matched.
        !           773: 
        !           774:      This feature can be used, for example, on a machine that whose
        !           775:      multiply and add instructions don't use an MQ register but which
        !           776:      has an add-accumulate instruction that does clobber the MQ
        !           777:      register.  Similarly, a combined instruction might require a
        !           778:      temporary register while the constituent instructions might not.
        !           779: 
        !           780:      When a `clobber' expression for a register appears inside a
        !           781:      `parallel' with other side effects, the register allocator
        !           782:      guarantees that the register is unoccupied both before and after
        !           783:      that insn.  However, the reload phase may allocate a register used
        !           784:      for one of the inputs unless the `&' constraint is specified for
        !           785:      the selected alternative (*note Modifiers::.).  You can clobber
        !           786:      either a specific hard register, a pseudo register, or a `scratch'
        !           787:      expression; in the latter two cases, GNU CC will allocate a hard
        !           788:      register that is available there for use as a temporary.
        !           789: 
        !           790:      For instructions that require a temporary register, you should use
        !           791:      `scratch' instead of a pseudo-register because this will allow the
        !           792:      combiner phase to add the `clobber' when required.  You do this by
        !           793:      coding (`clobber' (`match_scratch' ...)).  If you do clobber a
        !           794:      pseudo register, use one which appears nowhere else--generate a
        !           795:      new one each time.  Otherwise, you may confuse CSE.
        !           796: 
        !           797:      There is one other known use for clobbering a pseudo register in a
        !           798:      `parallel': when one of the input operands of the insn is also
        !           799:      clobbered by the insn.  In this case, using the same pseudo
        !           800:      register in the clobber and elsewhere in the insn produces the
        !           801:      expected results.
        !           802: 
        !           803: `(use X)'
        !           804:      Represents the use of the value of X.  It indicates that the value
        !           805:      in X at this point in the program is needed, even though it may
        !           806:      not be apparent why this is so.  Therefore, the compiler will not
        !           807:      attempt to delete previous instructions whose only effect is to
        !           808:      store a value in X.  X must be a `reg' expression.
        !           809: 
        !           810:      During the delayed branch scheduling phase, X may be an insn.
        !           811:      This indicates that X previously was located at this place in the
        !           812:      code and its data dependencies need to be taken into account.
        !           813:      These `use' insns will be deleted before the delayed branch
        !           814:      scheduling phase exits.
        !           815: 
        !           816: `(parallel [X0 X1 ...])'
        !           817:      Represents several side effects performed in parallel.  The square
        !           818:      brackets stand for a vector; the operand of `parallel' is a vector
        !           819:      of expressions.  X0, X1 and so on are individual side effect
        !           820:      expressions--expressions of code `set', `call', `return',
        !           821:      `clobber' or `use'.
        !           822: 
        !           823:      "In parallel" means that first all the values used in the
        !           824:      individual side-effects are computed, and second all the actual
        !           825:      side-effects are performed.  For example,
        !           826: 
        !           827:           (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1)))
        !           828:                      (set (mem:SI (reg:SI 1)) (reg:SI 1))])
        !           829: 
        !           830:      says unambiguously that the values of hard register 1 and the
        !           831:      memory location addressed by it are interchanged.  In both places
        !           832:      where `(reg:SI 1)' appears as a memory address it refers to the
        !           833:      value in register 1 *before* the execution of the insn.
        !           834: 
        !           835:      It follows that it is *incorrect* to use `parallel' and expect the
        !           836:      result of one `set' to be available for the next one.  For
        !           837:      example, people sometimes attempt to represent a jump-if-zero
        !           838:      instruction this way:
        !           839: 
        !           840:           (parallel [(set (cc0) (reg:SI 34))
        !           841:                      (set (pc) (if_then_else
        !           842:                                   (eq (cc0) (const_int 0))
        !           843:                                   (label_ref ...)
        !           844:                                   (pc)))])
        !           845: 
        !           846:      But this is incorrect, because it says that the jump condition
        !           847:      depends on the condition code value *before* this instruction, not
        !           848:      on the new value that is set by this instruction.
        !           849: 
        !           850:      Peephole optimization, which takes place together with final
        !           851:      assembly code output, can produce insns whose patterns consist of
        !           852:      a `parallel' whose elements are the operands needed to output the
        !           853:      resulting assembler code--often `reg', `mem' or constant
        !           854:      expressions.  This would not be well-formed RTL at any other stage
        !           855:      in compilation, but it is ok then because no further optimization
        !           856:      remains to be done.  However, the definition of the macro
        !           857:      `NOTICE_UPDATE_CC', if any, must deal with such insns if you
        !           858:      define any peephole optimizations.
        !           859: 
        !           860: `(sequence [INSNS ...])'
        !           861:      Represents a sequence of insns.  Each of the INSNS that appears in
        !           862:      the vector is suitable for appearing in the chain of insns, so it
        !           863:      must be an `insn', `jump_insn', `call_insn', `code_label',
        !           864:      `barrier' or `note'.
        !           865: 
        !           866:      A `sequence' RTX is never placed in an actual insn during RTL
        !           867:      generation.  It represents the sequence of insns that result from a
        !           868:      `define_expand' *before* those insns are passed to `emit_insn' to
        !           869:      insert them in the chain of insns.  When actually inserted, the
        !           870:      individual sub-insns are separated out and the `sequence' is
        !           871:      forgotten.
        !           872: 
        !           873:      After delay-slot scheduling is completed, an insn and all the
        !           874:      insns that reside in its delay slots are grouped together into a
        !           875:      `sequence'.  The insn requiring the delay slot is the first insn
        !           876:      in the vector; subsequent insns are to be placed in the delay slot.
        !           877: 
        !           878:      `INSN_ANNULLED_BRANCH_P' is set on an insn in a delay slot to
        !           879:      indicate that a branch insn should be used that will conditionally
        !           880:      annul the effect of the insns in the delay slots.  In such a case,
        !           881:      `INSN_FROM_TARGET_P' indicates that the insn is from the target of
        !           882:      the branch and should be executed only if the branch is taken;
        !           883:      otherwise the insn should be executed only if the branch is not
        !           884:      taken.  *Note Delay Slots::.
        !           885: 
        !           886:    These expression codes appear in place of a side effect, as the body
        !           887: of an insn, though strictly speaking they do not always describe side
        !           888: effects as such:
        !           889: 
        !           890: `(asm_input S)'
        !           891:      Represents literal assembler code as described by the string S.
        !           892: 
        !           893: `(unspec [OPERANDS ...] INDEX)'
        !           894: `(unspec_volatile [OPERANDS ...] INDEX)'
        !           895:      Represents a machine-specific operation on OPERANDS.  INDEX
        !           896:      selects between multiple machine-specific operations.
        !           897:      `unspec_volatile' is used for volatile operations and operations
        !           898:      that may trap; `unspec' is used for other operations.
        !           899: 
        !           900:      These codes may appear inside a `pattern' of an insn, inside a
        !           901:      `parallel', or inside an expression.
        !           902: 
        !           903: `(addr_vec:M [LR0 LR1 ...])'
        !           904:      Represents a table of jump addresses.  The vector elements LR0,
        !           905:      etc., are `label_ref' expressions.  The mode M specifies how much
        !           906:      space is given to each address; normally M would be `Pmode'.
        !           907: 
        !           908: `(addr_diff_vec:M BASE [LR0 LR1 ...])'
        !           909:      Represents a table of jump addresses expressed as offsets from
        !           910:      BASE.  The vector elements LR0, etc., are `label_ref' expressions
        !           911:      and so is BASE.  The mode M specifies how much space is given to
        !           912:      each address-difference.
        !           913: 
        !           914: 
        !           915: File: gcc.info,  Node: Incdec,  Next: Assembler,  Prev: Side Effects,  Up: RTL
        !           916: 
        !           917: Embedded Side-Effects on Addresses
        !           918: ==================================
        !           919: 
        !           920:    Four special side-effect expression codes appear as memory addresses.
        !           921: 
        !           922: `(pre_dec:M X)'
        !           923:      Represents the side effect of decrementing X by a standard amount
        !           924:      and represents also the value that X has after being decremented.
        !           925:      x must be a `reg' or `mem', but most machines allow only a `reg'.
        !           926:      m must be the machine mode for pointers on the machine in use.
        !           927:      The amount X is decremented by is the length in bytes of the
        !           928:      machine mode of the containing memory reference of which this
        !           929:      expression serves as the address.  Here is an example of its use:
        !           930: 
        !           931:           (mem:DF (pre_dec:SI (reg:SI 39)))
        !           932: 
        !           933:      This says to decrement pseudo register 39 by the length of a
        !           934:      `DFmode' value and use the result to address a `DFmode' value.
        !           935: 
        !           936: `(pre_inc:M X)'
        !           937:      Similar, but specifies incrementing X instead of decrementing it.
        !           938: 
        !           939: `(post_dec:M X)'
        !           940:      Represents the same side effect as `pre_dec' but a different
        !           941:      value.  The value represented here is the value X has before being
        !           942:      decremented.
        !           943: 
        !           944: `(post_inc:M X)'
        !           945:      Similar, but specifies incrementing X instead of decrementing it.
        !           946: 
        !           947:    These embedded side effect expressions must be used with care.
        !           948: Instruction patterns may not use them.  Until the `flow' pass of the
        !           949: compiler, they may occur only to represent pushes onto the stack.  The
        !           950: `flow' pass finds cases where registers are incremented or decremented
        !           951: in one instruction and used as an address shortly before or after;
        !           952: these cases are then transformed to use pre- or post-increment or
        !           953: -decrement.
        !           954: 
        !           955:    If a register used as the operand of these expressions is used in
        !           956: another address in an insn, the original value of the register is used.
        !           957: Uses of the register outside of an address are not permitted within the
        !           958: same insn as a use in an embedded side effect expression because such
        !           959: insns behave differently on different machines and hence must be treated
        !           960: as ambiguous and disallowed.
        !           961: 
        !           962:    An instruction that can be represented with an embedded side effect
        !           963: could also be represented using `parallel' containing an additional
        !           964: `set' to describe how the address register is altered.  This is not
        !           965: done because machines that allow these operations at all typically
        !           966: allow them wherever a memory address is called for.  Describing them as
        !           967: additional parallel stores would require doubling the number of entries
        !           968: in the machine description.
        !           969: 
        !           970: 
        !           971: File: gcc.info,  Node: Assembler,  Next: Insns,  Prev: Incdec,  Up: RTL
        !           972: 
        !           973: Assembler Instructions as Expressions
        !           974: =====================================
        !           975: 
        !           976:    The RTX code `asm_operands' represents a value produced by a
        !           977: user-specified assembler instruction.  It is used to represent an `asm'
        !           978: statement with arguments.  An `asm' statement with a single output
        !           979: operand, like this:
        !           980: 
        !           981:      asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z));
        !           982: 
        !           983: is represented using a single `asm_operands' RTX which represents the
        !           984: value that is stored in `outputvar':
        !           985: 
        !           986:      (set RTX-FOR-OUTPUTVAR
        !           987:           (asm_operands "foo %1,%2,%0" "a" 0
        !           988:                         [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z]
        !           989:                         [(asm_input:M1 "g")
        !           990:                          (asm_input:M2 "di")]))
        !           991: 
        !           992: Here the operands of the `asm_operands' RTX are the assembler template
        !           993: string, the output-operand's constraint, the index-number of the output
        !           994: operand among the output operands specified, a vector of input operand
        !           995: RTX's, and a vector of input-operand modes and constraints.  The mode
        !           996: M1 is the mode of the sum `x+y'; M2 is that of `*z'.
        !           997: 
        !           998:    When an `asm' statement has multiple output values, its insn has
        !           999: several such `set' RTX's inside of a `parallel'.  Each `set' contains a
        !          1000: `asm_operands'; all of these share the same assembler template and
        !          1001: vectors, but each contains the constraint for the respective output
        !          1002: operand.  They are also distinguished by the output-operand index
        !          1003: number, which is 0, 1, ... for successive output operands.
        !          1004: 

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