Return to gcc.info-4 CVS log

Up to [GCC 1.x] / gcc

Annotation of gcc/gcc.info-4, revision 1.1

1.1     ! root        1: Info file gcc.info, produced by Makeinfo, -*- Text -*- from input
        !             2: file gcc.texinfo.
        !             3: 
        !             4: This file documents the use and the internals of the GNU compiler.
        !             5: 
        !             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: 
        !            26: 
        !            27: 
        !            28: File: gcc.info,  Node: Comparisons,  Next: Bit Fields,  Prev: Arithmetic,  Up: RTL
        !            29: 
        !            30: Comparison Operations
        !            31: =====================
        !            32: 
        !            33: Comparison operators test a relation on two operands and are
        !            34: considered to represent the value 1 if the relation holds, or zero if
        !            35: it does not.  The mode of the comparison is determined by the
        !            36: operands; they must both be valid for a common machine mode.  A
        !            37: comparison with both operands constant would be invalid as the
        !            38: machine mode could not be deduced from it, but such a comparison
        !            39: should never exist in RTL due to constant folding.
        !            40: 
        !            41: Inequality comparisons come in two flavors, signed and unsigned. 
        !            42: Thus, there are distinct expression codes `gt' and `gtu' for signed
        !            43: and unsigned greater-than.  These can produce different results for
        !            44: the same pair of integer values: for example, 1 is signed
        !            45: greater-than -1 but not unsigned greater-than, because -1 when
        !            46: regarded as unsigned is actually `0xffffffff' which is greater than 1.
        !            47: 
        !            48: The signed comparisons are also used for floating point values. 
        !            49: Floating point comparisons are distinguished by the machine modes of
        !            50: the operands.
        !            51: 
        !            52: The comparison operators may be used to compare the condition codes
        !            53: `(cc0)' against zero, as in `(eq (cc0) (const_int 0))'.  Such a
        !            54: construct actually refers to the result of the preceding instruction
        !            55: in which the condition codes were set.  The above example stands for
        !            56: 1 if the condition codes were set to say ``zero'' or ``equal'', 0
        !            57: otherwise.  Although the same comparison operators are used for this
        !            58: as may be used in other contexts on actual data, no confusion can
        !            59: result since the machine description would never allow both kinds of
        !            60: uses in the same context.
        !            61: 
        !            62: `(eq X Y)'
        !            63:      1 if the values represented by X and Y are equal, otherwise 0.
        !            64: 
        !            65: `(ne X Y)'
        !            66:      1 if the values represented by X and Y are not equal, otherwise 0.
        !            67: 
        !            68: `(gt X Y)'
        !            69:      1 if the X is greater than Y.  If they are fixed-point, the
        !            70:      comparison is done in a signed sense.
        !            71: 
        !            72: `(gtu X Y)'
        !            73:      Like `gt' but does unsigned comparison, on fixed-point numbers
        !            74:      only.
        !            75: 
        !            76: `(lt X Y)'
        !            77: `(ltu X Y)'
        !            78:      Like `gt' and `gtu' but test for ``less than''.
        !            79: 
        !            80: `(ge X Y)'
        !            81: `(geu X Y)'
        !            82:      Like `gt' and `gtu' but test for ``greater than or equal''.
        !            83: 
        !            84: `(le X Y)'
        !            85: `(leu X Y)'
        !            86:      Like `gt' and `gtu' but test for ``less than or equal''.
        !            87: 
        !            88: `(if_then_else COND THEN ELSE)'
        !            89:      This is not a comparison operation but is listed here because it
        !            90:      is always used in conjunction with a comparison operation.  To
        !            91:      be precise, COND is a comparison expression.  This expression
        !            92:      represents a choice, according to COND, between the value
        !            93:      represented by THEN and the one represented by ELSE.
        !            94: 
        !            95:      On most machines, `if_then_else' expressions are valid only to
        !            96:      express conditional jumps.
        !            97: 
        !            98: 
        !            99: 
        !           100: File: gcc.info,  Node: Bit Fields,  Next: Conversions,  Prev: Comparisons,  Up: RTL
        !           101: 
        !           102: Bit-fields
        !           103: ==========
        !           104: 
        !           105: Special expression codes exist to represent bit-field instructions. 
        !           106: These types of expressions are lvalues in RTL; they may appear on the
        !           107: left side of a assignment, indicating insertion of a value into the
        !           108: specified bit field.
        !           109: 
        !           110: `(sign_extract:SI LOC SIZE POS)'
        !           111:      This represents a reference to a sign-extended bit-field
        !           112:      contained or starting in LOC (a memory or register reference). 
        !           113:      The bit field is SIZE bits wide and starts at bit POS.  The
        !           114:      compilation option `BITS_BIG_ENDIAN' says which end of the
        !           115:      memory unit POS counts from.
        !           116: 
        !           117:      Which machine modes are valid for LOC depends on the machine,
        !           118:      but typically LOC should be a single byte when in memory or a
        !           119:      full word in a register.
        !           120: 
        !           121: `(zero_extract:SI LOC SIZE POS)'
        !           122:      Like `sign_extract' but refers to an unsigned or zero-extended
        !           123:      bit field.  The same sequence of bits are extracted, but they
        !           124:      are filled to an entire word with zeros instead of by
        !           125:      sign-extension.
        !           126: 
        !           127: 
        !           128: 
        !           129: File: gcc.info,  Node: Conversions,  Next: RTL Declarations,  Prev: Bit Fields,  Up: RTL
        !           130: 
        !           131: Conversions
        !           132: ===========
        !           133: 
        !           134: All conversions between machine modes must be represented by explicit
        !           135: conversion operations.  For example, an expression which is the sum
        !           136: of a byte and a full word cannot be written as `(plus:SI (reg:QI 34)
        !           137: (reg:SI 80))' because the `plus' operation requires two operands of
        !           138: the same machine mode.  Therefore, the byte-sized operand is enclosed
        !           139: in a conversion operation, as in
        !           140: 
        !           141:      (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80))
        !           142: 
        !           143: The conversion operation is not a mere placeholder, because there may
        !           144: be more than one way of converting from a given starting mode to the
        !           145: desired final mode.  The conversion operation code says how to do it.
        !           146: 
        !           147: `(sign_extend:M X)'
        !           148:      Represents the result of sign-extending the value X to machine
        !           149:      mode M.  M must be a fixed-point mode and X a fixed-point value
        !           150:      of a mode narrower than M.
        !           151: 
        !           152: `(zero_extend:M X)'
        !           153:      Represents the result of zero-extending the value X to machine
        !           154:      mode M.  M must be a fixed-point mode and X a fixed-point value
        !           155:      of a mode narrower than M.
        !           156: 
        !           157: `(float_extend:M X)'
        !           158:      Represents the result of extending the value X to machine mode
        !           159:      M.  M must be a floating point mode and X a floating point value
        !           160:      of a mode narrower than M.
        !           161: 
        !           162: `(truncate:M X)'
        !           163:      Represents the result of truncating the value X to machine mode
        !           164:      M.  M must be a fixed-point mode and X a fixed-point value of a
        !           165:      mode wider than M.
        !           166: 
        !           167: `(float_truncate:M X)'
        !           168:      Represents the result of truncating the value X to machine mode
        !           169:      M.  M must be a floating point mode and X a floating point value
        !           170:      of a mode wider than M.
        !           171: 
        !           172: `(float:M X)'
        !           173:      Represents the result of converting fixed point value X,
        !           174:      regarded as signed, to floating point mode M.
        !           175: 
        !           176: `(unsigned_float:M X)'
        !           177:      Represents the result of converting fixed point value X,
        !           178:      regarded as unsigned, to floating point mode M.
        !           179: 
        !           180: `(fix:M X)'
        !           181:      When M is a fixed point mode, represents the result of
        !           182:      converting floating point value X to mode M, regarded as signed.
        !           183:      How rounding is done is not specified, so this operation may be
        !           184:      used validly in compiling C code only for integer-valued operands.
        !           185: 
        !           186: `(unsigned_fix:M X)'
        !           187:      Represents the result of converting floating point value X to
        !           188:      fixed point mode M, regarded as unsigned.  How rounding is done
        !           189:      is not specified.
        !           190: 
        !           191: `(fix:M X)'
        !           192:      When M is a floating point mode, represents the result of
        !           193:      converting floating point value X (valid for mode M) to an
        !           194:      integer, still represented in floating point mode M, by rounding
        !           195:      towards zero.
        !           196: 
        !           197: 
        !           198: 
        !           199: File: gcc.info,  Node: RTL Declarations,  Next: Side Effects,  Prev: Conversions,  Up: RTL
        !           200: 
        !           201: Declarations
        !           202: ============
        !           203: 
        !           204: Declaration expression codes do not represent arithmetic operations
        !           205: but rather state assertions about their operands.
        !           206: 
        !           207: `(strict_low_part (subreg:M (reg:N R) 0))'
        !           208:      This expression code is used in only one context: operand 0 of a
        !           209:      `set' expression.  In addition, the operand of this expression
        !           210:      must be a `subreg' expression.
        !           211: 
        !           212:      The presence of `strict_low_part' says that the part of the
        !           213:      register which is meaningful in mode N, but is not part of mode
        !           214:      M, is not to be altered.  Normally, an assignment to such a
        !           215:      subreg is allowed to have undefined effects on the rest of the
        !           216:      register when M is less than a word.
        !           217: 
        !           218: 
        !           219: 
        !           220: File: gcc.info,  Node: Side Effects,  Next: Incdec,  Prev: RTL Declarations,  Up: RTL
        !           221: 
        !           222: Side Effect Expressions
        !           223: =======================
        !           224: 
        !           225: The expression codes described so far represent values, not actions. 
        !           226: But machine instructions never produce values; they are meaningful
        !           227: only for their side effects on the state of the machine.  Special
        !           228: expression codes are used to represent side effects.
        !           229: 
        !           230: The body of an instruction is always one of these side effect codes;
        !           231: the codes described above, which represent values, appear only as the
        !           232: operands of these.
        !           233: 
        !           234: `(set LVAL X)'
        !           235:      Represents the action of storing the value of X into the place
        !           236:      represented by LVAL.  LVAL must be an expression representing a
        !           237:      place that can be stored in: `reg' (or `subreg' or
        !           238:      `strict_low_part'), `mem', `pc' or `cc0'.
        !           239: 
        !           240:      If LVAL is a `reg', `subreg' or `mem', it has a machine mode;
        !           241:      then X must be valid for that mode.
        !           242: 
        !           243:      If LVAL is a `reg' whose machine mode is less than the full
        !           244:      width of the register, then it means that the part of the
        !           245:      register specified by the machine mode is given the specified
        !           246:      value and the rest of the register receives an undefined value. 
        !           247:      Likewise, if LVAL is a `subreg' whose machine mode is narrower
        !           248:      than `SImode', the rest of the register can be changed in an
        !           249:      undefined way.
        !           250: 
        !           251:      If LVAL is a `strict_low_part' of a `subreg', then the part of
        !           252:      the register specified by the machine mode of the `subreg' is
        !           253:      given the value X and the rest of the register is not changed.
        !           254: 
        !           255:      If LVAL is `(cc0)', it has no machine mode, and X may have any
        !           256:      mode.  This represents a ``test'' or ``compare'' instruction.
        !           257: 
        !           258:      If LVAL is `(pc)', we have a jump instruction, and the
        !           259:      possibilities for X are very limited.  It may be a `label_ref'
        !           260:      expression (unconditional jump).  It may be an `if_then_else'
        !           261:      (conditional jump), in which case either the second or the third
        !           262:      operand must be `(pc)' (for the case which does not jump) and
        !           263:      the other of the two must be a `label_ref' (for the case which
        !           264:      does jump).  X may also be a `mem' or `(plus:SI (pc) Y)', where
        !           265:      Y may be a `reg' or a `mem'; these unusual patterns are used to
        !           266:      represent jumps through branch tables.
        !           267: 
        !           268: `(return)'
        !           269:      Represents a return from the current function, on machines where
        !           270:      this can be done with one instruction, such as Vaxes.  On
        !           271:      machines where a multi-instruction ``epilogue'' must be executed
        !           272:      in order to return from the function, returning is done by
        !           273:      jumping to a label which precedes the epilogue, and the `return'
        !           274:      expression code is never used.
        !           275: 
        !           276: `(call FUNCTION NARGS)'
        !           277:      Represents a function call.  FUNCTION is a `mem' expression
        !           278:      whose address is the address of the function to be called. 
        !           279:      NARGS is an expression which can be used for two purposes: on
        !           280:      some machines it represents the number of bytes of stack
        !           281:      argument; on others, it represents the number of argument
        !           282:      registers.
        !           283: 
        !           284:      Each machine has a standard machine mode which FUNCTION must
        !           285:      have.  The machine description defines macro `FUNCTION_MODE' to
        !           286:      expand into the requisite mode name.  The purpose of this mode
        !           287:      is to specify what kind of addressing is allowed, on machines
        !           288:      where the allowed kinds of addressing depend on the machine mode
        !           289:      being addressed.
        !           290: 
        !           291: `(clobber X)'
        !           292:      Represents the storing or possible storing of an unpredictable,
        !           293:      undescribed value into X, which must be a `reg' or `mem'
        !           294:      expression.
        !           295: 
        !           296:      One place this is used is in string instructions that store
        !           297:      standard values into particular hard registers.  It may not be
        !           298:      worth the trouble to describe the values that are stored, but it
        !           299:      is essential to inform the compiler that the registers will be
        !           300:      altered, lest it attempt to keep data in them across the string
        !           301:      instruction.
        !           302: 
        !           303:      X may also be null--a null C pointer, no expression at all. 
        !           304:      Such a `(clobber (null))' expression means that all memory
        !           305:      locations must be presumed clobbered.
        !           306: 
        !           307:      Note that the machine description classifies certain hard
        !           308:      registers as ``call-clobbered''.  All function call instructions
        !           309:      are assumed by default to clobber these registers, so there is
        !           310:      no need to use `clobber' expressions to indicate this fact. 
        !           311:      Also, each function call is assumed to have the potential to
        !           312:      alter any memory location.
        !           313: 
        !           314: `(use X)'
        !           315:      Represents the use of the value of X.  It indicates that the
        !           316:      value in X at this point in the program is needed, even though
        !           317:      it may not be apparent why this is so.  Therefore, the compiler
        !           318:      will not attempt to delete instructions whose only effect is to
        !           319:      store a value in X.  X must be a `reg' expression.
        !           320: 
        !           321: `(parallel [X0 X1 ...])'
        !           322:      Represents several side effects performed in parallel.  The
        !           323:      square brackets stand for a vector; the operand of `parallel' is
        !           324:      a vector of expressions.  X0, X1 and so on are individual side
        !           325:      effects--expressions of code `set', `call', `return', `clobber'
        !           326:      or `use'.
        !           327: 
        !           328:      ``In parallel'' means that first all the values used in the
        !           329:      individual side-effects are computed, and second all the actual
        !           330:      side-effects are performed.  For example,
        !           331: 
        !           332:           (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1)))
        !           333:                      (set (mem:SI (reg:SI 1)) (reg:SI 1))])
        !           334: 
        !           335:      says unambiguously that the values of hard register 1 and the
        !           336:      memory location addressed by it are interchanged.  In both
        !           337:      places where `(reg:SI 1)' appears as a memory address it refers
        !           338:      to the value in register 1 *before* the execution of the
        !           339:      instruction.
        !           340: 
        !           341:      Peephole optimization, which takes place in the last
        !           342:      jump-optimization pass, can produce insns whose patterns consist
        !           343:      of a `parallel' whose elements are the operands needed to output
        !           344:      the resulting assembler code--often `reg', `mem' or constant
        !           345:      expressions.  This would not be well-formed RTL at any other
        !           346:      stage in compilation, but it is ok then because no further
        !           347:      optimization remains to be done.  However, the definition of the
        !           348:      macro `NOTICE_UPDATE_CC' may need to deal with such insns.
        !           349: 
        !           350: `(sequence [INSNS ...])'
        !           351:      Represents a sequence of insns.  Each of the INSNS that appears
        !           352:      in the vector is suitable for appearing in the chain of insns,
        !           353:      so it must be an `insn', `jump_insn', `call_insn', `code_label',
        !           354:      `barrier' or `note'.
        !           355: 
        !           356:      A `sequence' RTX never appears in an actual insn.  It represents
        !           357:      the sequence of insns that result from a `define_expand'
        !           358:      *before* those insns are passed to `emit_insn' to insert them in
        !           359:      the chain of insns.  When actually inserted, the individual
        !           360:      sub-insns are separated out and the `sequence' is forgotten.
        !           361: 
        !           362: Three expression codes appear in place of a side effect, as the body
        !           363: of an insn, though strictly speaking they do not describe side
        !           364: effects as such:
        !           365: 
        !           366: `(asm_input S)'
        !           367:      Represents literal assembler code as described by the string S.
        !           368: 
        !           369: `(addr_vec:M [LR0 LR1 ...])'
        !           370:      Represents a table of jump addresses.  The vector elements LR0,
        !           371:      etc., are `label_ref' expressions.  The mode M specifies how
        !           372:      much space is given to each address; normally M would be `Pmode'.
        !           373: 
        !           374: `(addr_diff_vec:M BASE [LR0 LR1 ...])'
        !           375:      Represents a table of jump addresses expressed as offsets from
        !           376:      BASE.  The vector elements LR0, etc., are `label_ref'
        !           377:      expressions and so is BASE.  The mode M specifies how much space
        !           378:      is given to each address-difference.
        !           379: 
        !           380: 
        !           381: 
        !           382: File: gcc.info,  Node: Incdec,  Next: Assembler,  Prev: Side Effects,  Up: RTL
        !           383: 
        !           384: Embedded Side-Effects on Addresses
        !           385: ==================================
        !           386: 
        !           387: Four special side-effect expression codes appear as memory addresses.
        !           388: 
        !           389: `(pre_dec:M X)'
        !           390:      Represents the side effect of decrementing X by a standard
        !           391:      amount and represents also the value that X has after being
        !           392:      decremented.  X must be a `reg' or `mem', but most machines
        !           393:      allow only a `reg'.  M must be the machine mode for pointers on
        !           394:      the machine in use.  The amount X is decremented by is the
        !           395:      length in bytes of the machine mode of the containing memory
        !           396:      reference of which this expression serves as the address.  Here
        !           397:      is an example of its use:
        !           398: 
        !           399:           (mem:DF (pre_dec:SI (reg:SI 39)))
        !           400: 
        !           401:      This says to decrement pseudo register 39 by the length of a
        !           402:      `DFmode' value and use the result to address a `DFmode' value.
        !           403: 
        !           404: `(pre_inc:M X)'
        !           405:      Similar, but specifies incrementing X instead of decrementing it.
        !           406: 
        !           407: `(post_dec:M X)'
        !           408:      Represents the same side effect as `pre_decrement' but a
        !           409:      different value.  The value represented here is the value X has
        !           410:      before being decremented.
        !           411: 
        !           412: `(post_inc:M X)'
        !           413:      Similar, but specifies incrementing X instead of decrementing it.
        !           414: 
        !           415: These embedded side effect expressions must be used with care. 
        !           416: Instruction patterns may not use them.  Until the `flow' pass of the
        !           417: compiler, they may occur only to represent pushes onto the stack. 
        !           418: The `flow' pass finds cases where registers are incremented or
        !           419: decremented in one instruction and used as an address shortly before
        !           420: or after; these cases are then transformed to use pre- or
        !           421: post-increment or -decrement.
        !           422: 
        !           423: Explicit popping of the stack could be represented with these
        !           424: embedded side effect operators, but that would not be safe; the
        !           425: instruction combination pass could move the popping past pushes, thus
        !           426: changing the meaning of the code.
        !           427: 
        !           428: An instruction that can be represented with an embedded side effect
        !           429: could also be represented using `parallel' containing an additional
        !           430: `set' to describe how the address register is altered.  This is not
        !           431: done because machines that allow these operations at all typically
        !           432: allow them wherever a memory address is called for.  Describing them
        !           433: as additional parallel stores would require doubling the number of
        !           434: entries in the machine description.
        !           435: 
        !           436: 
        !           437: 
        !           438: File: gcc.info,  Node: Assembler,  Next: Insns,  Prev: IncDec,  Up: RTL
        !           439: 
        !           440: Assembler Instructions as Expressions
        !           441: =====================================
        !           442: 
        !           443: The RTX code `asm_operands' represents a value produced by a
        !           444: user-specified assembler instruction.  It is used to represent an
        !           445: `asm' statement with arguments.  An `asm' statement with a single
        !           446: output operand, like this:
        !           447: 
        !           448:      asm ("foo %1,%2,%0" : "a" (outputvar) : "g" (x + y), "di" (*z));
        !           449: 
        !           450: is represented using a single `asm_operands' RTX which represents the
        !           451: value that is stored in `outputvar':
        !           452: 
        !           453:      (set RTX-FOR-OUTPUTVAR
        !           454:           (asm_operands "foo %1,%2,%0" "a" 0
        !           455:                         [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z]
        !           456:                         [(asm_input:M1 "g")
        !           457:                          (asm_input:M2 "di")]))
        !           458: 
        !           459: Here the operands of the `asm_operands' RTX are the assembler
        !           460: template string, the output-operand's constraint, the index-number of
        !           461: the output operand among the output operands specified, a vector of
        !           462: input operand RTX's, and a vector of input-operand modes and
        !           463: constraints.  The mode M1 is the mode of the sum `x+y'; M2 is that of
        !           464: `*z'.
        !           465: 
        !           466: When an `asm' statement has multiple output values, its insn has
        !           467: several such `set' RTX's inside of a `parallel'.  Each `set' contains
        !           468: a `asm_operands'; all of these share the same assembler template and
        !           469: vectors, but each contains the constraint for the respective output
        !           470: operand.  They are also distinguished by the output-operand index
        !           471: number, which is 0, 1, ... for successive output operands.
        !           472: 
        !           473: 
        !           474: 
        !           475: File: gcc.info,  Node: Insns,  Next: Calls,  Prev: Assembler,  Up: RTL
        !           476: 
        !           477: Insns
        !           478: =====
        !           479: 
        !           480: The RTL representation of the code for a function is a doubly-linked
        !           481: chain of objects called "insns".  Insns are expressions with special
        !           482: codes that are used for no other purpose.  Some insns are actual
        !           483: instructions; others represent dispatch tables for `switch'
        !           484: statements; others represent labels to jump to or various sorts of
        !           485: declarative information.
        !           486: 
        !           487: In addition to its own specific data, each insn must have a unique
        !           488: id-number that distinguishes it from all other insns in the current
        !           489: function, and chain pointers to the preceding and following insns. 
        !           490: These three fields occupy the same position in every insn,
        !           491: independent of the expression code of the insn.  They could be
        !           492: accessed with `XEXP' and `XINT', but instead three special macros are
        !           493: always used:
        !           494: 
        !           495: `INSN_UID (I)'
        !           496:      Accesses the unique id of insn I.
        !           497: 
        !           498: `PREV_INSN (I)'
        !           499:      Accesses the chain pointer to the insn preceding I.  If I is the
        !           500:      first insn, this is a null pointer.
        !           501: 
        !           502: `NEXT_INSN (I)'
        !           503:      Accesses the chain pointer to the insn following I.  If I is the
        !           504:      last insn, this is a null pointer.
        !           505: 
        !           506: The `NEXT_INSN' and `PREV_INSN' pointers must always correspond: if I
        !           507: is not the first insn,
        !           508: 
        !           509:      NEXT_INSN (PREV_INSN (INSN)) == INSN
        !           510: 
        !           511: is always true.
        !           512: 
        !           513: Every insn has one of the following six expression codes:
        !           514: 
        !           515: `insn'
        !           516:      The expression code `insn' is used for instructions that do not
        !           517:      jump and do not do function calls.  Insns with code `insn' have
        !           518:      four additional fields beyond the three mandatory ones listed
        !           519:      above.  These four are described in a table below.
        !           520: 
        !           521: `jump_insn'
        !           522:      The expression code `jump_insn' is used for instructions that
        !           523:      may jump (or, more generally, may contain `label_ref'
        !           524:      expressions).  `jump_insn' insns have the same extra fields as
        !           525:      `insn' insns, accessed in the same way.
        !           526: 
        !           527: `call_insn'
        !           528:      The expression code `call_insn' is used for instructions that
        !           529:      may do function calls.  It is important to distinguish these
        !           530:      instructions because they imply that certain registers and
        !           531:      memory locations may be altered unpredictably.
        !           532: 
        !           533:      `call_insn' insns have the same extra fields as `insn' insns,
        !           534:      accessed in the same way.
        !           535: 
        !           536: `code_label'
        !           537:      A `code_label' insn represents a label that a jump insn can jump
        !           538:      to.  It contains one special field of data in addition to the
        !           539:      three standard ones.  It is used to hold the "label number", a
        !           540:      number that identifies this label uniquely among all the labels
        !           541:      in the compilation (not just in the current function). 
        !           542:      Ultimately, the label is represented in the assembler output as
        !           543:      an assembler label `LN' where N is the label number.
        !           544: 
        !           545: `barrier'
        !           546:      Barriers are placed in the instruction stream after
        !           547:      unconditional jump instructions to indicate that the jumps are
        !           548:      unconditional.  They contain no information beyond the three
        !           549:      standard fields.
        !           550: 
        !           551: `note'
        !           552:      `note' insns are used to represent additional debugging and
        !           553:      declarative information.  They contain two nonstandard fields,
        !           554:      an integer which is accessed with the macro `NOTE_LINE_NUMBER'
        !           555:      and a string accessed with `NOTE_SOURCE_FILE'.
        !           556: 
        !           557:      If `NOTE_LINE_NUMBER' is positive, the note represents the
        !           558:      position of a source line and `NOTE_SOURCE_FILE' is the source
        !           559:      file name that the line came from.  These notes control
        !           560:      generation of line number data in the assembler output.
        !           561: 
        !           562:      Otherwise, `NOTE_LINE_NUMBER' is not really a line number but a
        !           563:      code with one of the following values (and `NOTE_SOURCE_FILE'
        !           564:      must contain a null pointer):
        !           565: 
        !           566:     `NOTE_INSN_DELETED'
        !           567:           Such a note is completely ignorable.  Some passes of the
        !           568:           compiler delete insns by altering them into notes of this
        !           569:           kind.
        !           570: 
        !           571:     `NOTE_INSN_BLOCK_BEG'
        !           572:     `NOTE_INSN_BLOCK_END'
        !           573:           These types of notes indicate the position of the beginning
        !           574:           and end of a level of scoping of variable names.  They
        !           575:           control the output of debugging information.
        !           576: 
        !           577:     `NOTE_INSN_LOOP_BEG'
        !           578:     `NOTE_INSN_LOOP_END'
        !           579:           These types of notes indicate the position of the beginning
        !           580:           and end of a `while' or `for' loop.  They enable the loop
        !           581:           optimizer to find loops quickly.
        !           582: 
        !           583: Here is a table of the extra fields of `insn', `jump_insn' and
        !           584: `call_insn' insns:
        !           585: 
        !           586: `PATTERN (I)'
        !           587:      An expression for the side effect performed by this insn.
        !           588: 
        !           589: `REG_NOTES (I)'
        !           590:      A list (chain of `expr_list' expressions) giving information
        !           591:      about the usage of registers in this insn.  This list is set up
        !           592:      by the flow analysis pass; it is a null pointer until then.
        !           593: 
        !           594: `LOG_LINKS (I)'
        !           595:      A list (chain of `insn_list' expressions) of previous
        !           596:      ``related'' insns: insns which store into registers values that
        !           597:      are used for the first time in this insn.  (An additional
        !           598:      constraint is that neither a jump nor a label may come between
        !           599:      the related insns).  This list is set up by the flow analysis
        !           600:      pass; it is a null pointer until then.
        !           601: 
        !           602: `INSN_CODE (I)'
        !           603:      An integer that says which pattern in the machine description
        !           604:      matches this insn, or -1 if the matching has not yet been
        !           605:      attempted.
        !           606: 
        !           607:      Such matching is never attempted and this field is not used on
        !           608:      an insn whose pattern consists of a single `use', `clobber',
        !           609:      `asm', `addr_vec' or `addr_diff_vec' expression.
        !           610: 
        !           611: The `LOG_LINKS' field of an insn is a chain of `insn_list'
        !           612: expressions.  Each of these has two operands: the first is an insn,
        !           613: and the second is another `insn_list' expression (the next one in the
        !           614: chain).  The last `insn_list' in the chain has a null pointer as
        !           615: second operand.  The significant thing about the chain is which insns
        !           616: appear in it (as first operands of `insn_list' expressions).  Their
        !           617: order is not significant.
        !           618: 
        !           619: The `REG_NOTES' field of an insn is a similar chain but of
        !           620: `expr_list' expressions instead of `insn_list'.  There are four kinds
        !           621: of register notes, which are distinguished by the machine mode of the
        !           622: `expr_list', which a register note is really understood as being an
        !           623: `enum reg_note'.  The first operand OP of the `expr_list' is data
        !           624: whose meaning depends on the kind of note.  Here are the four kinds:
        !           625: 
        !           626: `REG_DEAD'
        !           627:      The register OP dies in this insn; that is to say, altering the
        !           628:      value immediately after this insn would not affect the future
        !           629:      behavior of the program.
        !           630: 
        !           631: `REG_INC'
        !           632:      The register OP is incremented (or decremented; at this level
        !           633:      there is no distinction) by an embedded side effect inside this
        !           634:      insn.  This means it appears in a `POST_INC', `PRE_INC',
        !           635:      `POST_DEC' or `PRE_DEC' RTX.
        !           636: 
        !           637: `REG_EQUIV'
        !           638:      The register that is set by this insn will be equal to OP at run
        !           639:      time, and could validly be replaced in all its occurrences by
        !           640:      OP.  (``Validly'' here refers to the data flow of the program;
        !           641:      simple replacement may make some insns invalid.)
        !           642: 
        !           643:      The value which the insn explicitly copies into the register may
        !           644:      look different from OP, but they will be equal at run time.
        !           645: 
        !           646:      For example, when a constant is loaded into a register that is
        !           647:      never assigned any other value, this kind of note is used.
        !           648: 
        !           649:      When a parameter is copied into a pseudo-register at entry to a
        !           650:      function, a note of this kind records that the register is
        !           651:      equivalent to the stack slot where the parameter was passed. 
        !           652:      Although in this case the register may be set by other insns, it
        !           653:      is still valid to replace the register by the stack slot
        !           654:      throughout the function.
        !           655: 
        !           656: `REG_EQUAL'
        !           657:      The register that is set by this insn will be equal to OP at run
        !           658:      time at the end of this insn (but not necessarily elsewhere in
        !           659:      the function).
        !           660: 
        !           661:      The RTX OP is typically an arithmetic expression.  For example,
        !           662:      when a sequence of insns such as a library call is used to
        !           663:      perform an arithmetic operation, this kind of note is attached
        !           664:      to the insn that produces or copies the final value.  It tells
        !           665:      the CSE pass how to think of that value.
        !           666: 
        !           667: `REG_RETVAL'
        !           668:      This insn copies the value of a library call, and OP is the
        !           669:      first insn that was generated to set up the arguments for the
        !           670:      library call.
        !           671: 
        !           672:      Flow analysis uses this note to delete all of a library call
        !           673:      whose result is dead.
        !           674: 
        !           675: `REG_WAS_0'
        !           676:      The register OP contained zero before this insn.  You can rely
        !           677:      on this note if it is present; its absence implies nothing.
        !           678: 
        !           679: `REG_LIBCALL'
        !           680:      This is the inverse of `REG_RETVAL': it is placed on the first
        !           681:      insn of a library call, and it points to the last one.
        !           682: 
        !           683:      Loop optimization uses this note to move an entire library call
        !           684:      out of a loop when its value is constant.
        !           685: 
        !           686: `REG_NONNEG'
        !           687:      The register OP is known to have nonnegative value when this
        !           688:      insn is reached.
        !           689: 
        !           690: (The only difference between the expression codes `insn_list' and
        !           691: `expr_list' is that the first operand of an `insn_list' is assumed to
        !           692: be an insn and is printed in debugging dumps as the insn's unique id;
        !           693: the first operand of an `expr_list' is printed in the ordinary way as
        !           694: an expression.)
        !           695: 
        !           696: 
        !           697: 
        !           698: File: gcc.info,  Node: Calls,  Next: Sharing,  Prev: Insns,  Up: RTL
        !           699: 
        !           700: RTL Representation of Function-Call Insns
        !           701: =========================================
        !           702: 
        !           703: Insns that call subroutines have the RTL expression code `call_insn'.
        !           704: These insns must satisfy special rules, and their bodies must use a
        !           705: special RTL expression code, `call'.
        !           706: 
        !           707: A `call' expression has two operands, as follows:
        !           708: 
        !           709:      (call NBYTES (mem:FM ADDR))
        !           710: 
        !           711: Here NBYTES is an operand that represents the number of bytes of
        !           712: argument data being passed to the subroutine, FM is a machine mode
        !           713: (which must equal as the definition of the `FUNCTION_MODE' macro in
        !           714: the machine description) and ADDR represents the address of the
        !           715: subroutine.
        !           716: 
        !           717: For a subroutine that returns no value, the `call' RTX as shown above
        !           718: is the entire body of the insn.
        !           719: 
        !           720: For a subroutine that returns a value whose mode is not `BLKmode',
        !           721: the value is returned in a hard register.  If this register's number
        !           722: is R, then the body of the call insn looks like this:
        !           723: 
        !           724:      (set (reg:M R)
        !           725:           (call NBYTES (mem:FM ADDR)))
        !           726: 
        !           727: This RTL expression makes it clear (to the optimizer passes) that the
        !           728: appropriate register receives a useful value in this insn.
        !           729: 
        !           730: Immediately after RTL generation, if the value of the subroutine is
        !           731: actually used, this call insn is always followed closely by an insn
        !           732: which refers to the register R.  This remains true through all the
        !           733: optimizer passes until cross jumping occurs.
        !           734: 
        !           735: The following insn has one of two forms.  Either it copies the value
        !           736: into a pseudo-register, like this:
        !           737: 
        !           738:      (set (reg:M P) (reg:M R))
        !           739: 
        !           740: or (in the case where the calling function will simply return
        !           741: whatever value the call produced, and no operation is needed to do
        !           742: this):
        !           743: 
        !           744:      (use (reg:M R))
        !           745: 
        !           746: Between the call insn and this following insn there may intervene
        !           747: only a stack-adjustment insn (and perhaps some `note' insns).
        !           748: 
        !           749: When a subroutine returns a `BLKmode' value, it is handled by passing
        !           750: to the subroutine the address of a place to store the value.  So the
        !           751: call insn itself does not ``return'' any value, and it has the same
        !           752: RTL form as a call that returns nothing.
        !           753: 
        !           754: 
        !           755: 
        !           756: File: gcc.info,  Node: Sharing,  Prev: Calls,  Up: RTL
        !           757: 
        !           758: Structure Sharing Assumptions
        !           759: =============================
        !           760: 
        !           761: The compiler assumes that certain kinds of RTL expressions are
        !           762: unique; there do not exist two distinct objects representing the same
        !           763: value.  In other cases, it makes an opposite assumption: that no RTL
        !           764: expression object of a certain kind appears in more than one place in
        !           765: the containing structure.
        !           766: 
        !           767: These assumptions refer to a single function; except for the RTL
        !           768: objects that describe global variables and external functions, no RTL
        !           769: objects are common to two functions.
        !           770: 
        !           771:    * Each pseudo-register has only a single `reg' object to represent
        !           772:      it, and therefore only a single machine mode.
        !           773: 
        !           774:    * For any symbolic label, there is only one `symbol_ref' object
        !           775:      referring to it.
        !           776: 
        !           777:    * There is only one `const_int' expression with value zero, and
        !           778:      only one with value one.
        !           779: 
        !           780:    * There is only one `pc' expression.
        !           781: 
        !           782:    * There is only one `cc0' expression.
        !           783: 
        !           784:    * There is only one `const_double' expression with mode `SFmode'
        !           785:      and value zero, and only one with mode `DFmode' and value zero.
        !           786: 
        !           787:    * No `label_ref' appears in more than one place in the RTL
        !           788:      structure; in other words, it is safe to do a tree-walk of all
        !           789:      the insns in the function and assume that each time a
        !           790:      `label_ref' is seen it is distinct from all others that are seen.
        !           791: 
        !           792:    * Only one `mem' object is normally created for each static
        !           793:      variable or stack slot, so these objects are frequently shared
        !           794:      in all the places they appear.  However, separate but equal
        !           795:      objects for these variables are occasionally made.
        !           796: 
        !           797:    * No RTL object appears in more than one place in the RTL
        !           798:      structure except as described above.  Many passes of the
        !           799:      compiler rely on this by assuming that they can modify RTL
        !           800:      objects in place without unwanted side-effects on other insns.
        !           801: 
        !           802:    * During initial RTL generation, shared structure is freely
        !           803:      introduced.  After all the RTL for a function has been
        !           804:      generated, all shared structure is copied by `unshare_all_rtl'
        !           805:      in `emit-rtl.c', after which the above rules are guaranteed to
        !           806:      be followed.
        !           807: 
        !           808:    * During the combiner pass, shared structure with an insn can
        !           809:      exist temporarily.  However, the shared structure is copied
        !           810:      before the combiner is finished with the insn.  This is done by
        !           811:      `copy_substitutions' in `combine.c'.
        !           812: 
        !           813: 
        !           814: 
        !           815: File: gcc.info,  Node: Machine Desc,  Next: Machine Macros,  Prev: RTL,  Up: Top
        !           816: 
        !           817: Machine Descriptions
        !           818: ********************
        !           819: 
        !           820: A machine description has two parts: a file of instruction patterns
        !           821: (`.md' file) and a C header file of macro definitions.
        !           822: 
        !           823: The `.md' file for a target machine contains a pattern for each
        !           824: instruction that the target machine supports (or at least each
        !           825: instruction that is worth telling the compiler about).  It may also
        !           826: contain comments.  A semicolon causes the rest of the line to be a
        !           827: comment, unless the semicolon is inside a quoted string.
        !           828: 
        !           829: See the next chapter for information on the C header file.
        !           830: 
        !           831: * Menu:
        !           832: 
        !           833: * Patterns::            How to write instruction patterns.
        !           834: * Example::             An explained example of a `define_insn' pattern.
        !           835: * RTL Template::        The RTL template defines what insns match a pattern.
        !           836: * Output Template::     The output template says how to make assembler code
        !           837:                           from such an insn.
        !           838: * Output Statement::    For more generality, write C code to output 
        !           839:                           the assembler code.
        !           840: * Constraints::         When not all operands are general operands.
        !           841: * Standard Names::      Names mark patterns to use for code generation.
        !           842: * Pattern Ordering::    When the order of patterns makes a difference.
        !           843: * Dependent Patterns::  Having one pattern may make you need another.
        !           844: * Jump Patterns::       Special considerations for patterns for jump insns.
        !           845: * Peephole Definitions::Defining machine-specific peephole optimizations.
        !           846: * Expander Definitions::Generating a sequence of several RTL insns
        !           847:                          for a standard operation.
        !           848: 
        !           849:  
        !           850: 
        !           851: File: gcc.info,  Node: Patterns,  Next: Example,  Prev: Machine Desc,  Up: Machine Desc
        !           852: 
        !           853: Everything about Instruction Patterns
        !           854: =====================================
        !           855: 
        !           856: Each instruction pattern contains an incomplete RTL expression, with
        !           857: pieces to be filled in later, operand constraints that restrict how
        !           858: the pieces can be filled in, and an output pattern or C code to
        !           859: generate the assembler output, all wrapped up in a `define_insn'
        !           860: expression.
        !           861: 
        !           862: A `define_insn' is an RTL expression containing four or five operands:
        !           863: 
        !           864:   1. An optional name.  The presence of a name indicate that this
        !           865:      instruction pattern can perform a certain standard job for the
        !           866:      RTL-generation pass of the compiler.  This pass knows certain
        !           867:      names and will use the instruction patterns with those names, if
        !           868:      the names are defined in the machine description.
        !           869: 
        !           870:      The absence of a name is indicated by writing an empty string
        !           871:      where the name should go.  Nameless instruction patterns are
        !           872:      never used for generating RTL code, but they may permit several
        !           873:      simpler insns to be combined later on.
        !           874: 
        !           875:      Names that are not thus known and used in RTL-generation have no
        !           876:      effect; they are equivalent to no name at all.
        !           877: 
        !           878:   2. The "RTL template" (*note RTL Template::.) is a vector of
        !           879:      incomplete RTL expressions which show what the instruction
        !           880:      should look like.  It is incomplete because it may contain
        !           881:      `match_operand' and `match_dup' expressions that stand for
        !           882:      operands of the instruction.
        !           883: 
        !           884:      If the vector has only one element, that element is what the
        !           885:      instruction should look like.  If the vector has multiple
        !           886:      elements, then the instruction looks like a `parallel'
        !           887:      expression containing that many elements as described.
        !           888: 
        !           889:   3. A condition.  This is a string which contains a C expression
        !           890:      that is the final test to decide whether an insn body matches
        !           891:      this pattern.
        !           892: 
        !           893:      For a named pattern, the condition (if present) may not depend
        !           894:      on the data in the insn being matched, but only the
        !           895:      target-machine-type flags.  The compiler needs to test these
        !           896:      conditions during initialization in order to learn exactly which
        !           897:      named instructions are available in a particular run.
        !           898: 
        !           899:      For nameless patterns, the condition is applied only when
        !           900:      matching an individual insn, and only after the insn has matched
        !           901:      the pattern's recognition template.  The insn's operands may be
        !           902:      found in the vector `operands'.
        !           903: 
        !           904:   4. The "output template": a string that says how to output matching
        !           905:      insns as assembler code.  `%' in this string specifies where to
        !           906:      substitute the value of an operand.  *Note Output Template::.
        !           907: 
        !           908:      When simple substitution isn't general enough, you can specify a
        !           909:      piece of C code to compute the output.  *Note Output Statement::.
        !           910: 
        !           911:   5. Optionally, some "machine-specific information".  The meaning of
        !           912:      this information is defined only by an individual machine
        !           913:      description; typically it might say whether this insn alters the
        !           914:      condition codes, or how many bytes of output it generates.
        !           915: 
        !           916:      This operand is written as a string containing a C initializer
        !           917:      (complete with braces) for the structure type
        !           918:      `INSN_MACHINE_INFO', whose definition is up to you (*note
        !           919:      Misc::.).
        !           920: 
        !           921: 
        !           922: 
        !           923: File: gcc.info,  Node: Example,  Next: RTL Template,  Prev: Patterns,  Up: Machine Desc
        !           924: 
        !           925: Example of `define_insn'
        !           926: ========================
        !           927: 
        !           928: Here is an actual example of an instruction pattern, for the
        !           929: 68000/68020.
        !           930: 
        !           931:      (define_insn "tstsi"
        !           932:        [(set (cc0)
        !           933:              (match_operand:SI 0 "general_operand" "rm"))]
        !           934:        ""
        !           935:        "*
        !           936:      { if (TARGET_68020 || ! ADDRESS_REG_P (operands[0]))
        !           937:          return \"tstl %0\";
        !           938:        return \"cmpl #0,%0\"; }")
        !           939: 
        !           940: This is an instruction that sets the condition codes based on the
        !           941: value of a general operand.  It has no condition, so any insn whose
        !           942: RTL description has the form shown may be handled according to this
        !           943: pattern.  The name `tstsi' means ``test a `SImode' value'' and tells
        !           944: the RTL generation pass that, when it is necessary to test such a
        !           945: value, an insn to do so can be constructed using this pattern.
        !           946: 
        !           947: The output control string is a piece of C code which chooses which
        !           948: output template to return based on the kind of operand and the
        !           949: specific type of CPU for which code is being generated.
        !           950: 
        !           951: `"rm"' is an operand constraint.  Its meaning is explained below.
        !           952: 
        !           953: 
        !           954: 
        !           955: File: gcc.info,  Node: RTL Template,  Next: Output Template,  Prev: Example,  Up: Machine Desc
        !           956: 
        !           957: RTL Template for Generating and Recognizing Insns
        !           958: =================================================
        !           959: 
        !           960: The RTL template is used to define which insns match the particular
        !           961: pattern and how to find their operands.  For named patterns, the RTL
        !           962: template also says how to construct an insn from specified operands.
        !           963: 
        !           964: Construction involves substituting specified operands into a copy of
        !           965: the template.  Matching involves determining the values that serve as
        !           966: the operands in the insn being matched.  Both of these activities are
        !           967: controlled by special expression types that direct matching and
        !           968: substitution of the operands.
        !           969: 
        !           970: `(match_operand:M N TESTFN CONSTRAINT)'
        !           971:      This expression is a placeholder for operand number N of the
        !           972:      insn.  When constructing an insn, operand number N will be
        !           973:      substituted at this point.  When matching an insn, whatever
        !           974:      appears at this position in the insn will be taken as operand
        !           975:      number N; but it must satisfy TESTFN or this instruction pattern
        !           976:      will not match at all.
        !           977: 
        !           978:      Operand numbers must be chosen consecutively counting from zero
        !           979:      in each instruction pattern.  There may be only one
        !           980:      `match_operand' expression in the pattern for each operand
        !           981:      number.  Usually operands are numbered in the order of
        !           982:      appearance in `match_operand' expressions.
        !           983: 
        !           984:      TESTFN is a string that is the name of a C function that accepts
        !           985:      two arguments, a machine mode and an expression.  During
        !           986:      matching, the function will be called with M as the mode
        !           987:      argument and the putative operand as the other argument.  If it
        !           988:      returns zero, this instruction pattern fails to match.  TESTFN
        !           989:      may be an empty string; then it means no test is to be done on
        !           990:      the operand.
        !           991: 
        !           992:      CONSTRAINT is explained later (*note Constraints::.).
        !           993: 
        !           994:      Most often, TESTFN is `"general_operand"'.  It checks that the
        !           995:      putative operand is either a constant, a register or a memory
        !           996:      reference, and that it is valid for mode M.
        !           997: 
        !           998:      For an operand that must be a register, TESTFN should be
        !           999:      `"register_operand"'.  It would be valid to use
        !          1000:      `"general_operand"', since the reload pass would copy any
        !          1001:      non-register operands through registers, but this would make GNU
        !          1002:      CC do extra work, and it would prevent the register allocator
        !          1003:      from doing the best possible job.
        !          1004: 
        !          1005:      For an operand that must be a constant, either TESTFN should be
        !          1006:      `"immediate_operand"', or the instruction pattern's extra
        !          1007:      condition should check for constants, or both.  You cannot
        !          1008:      expect the constraints to do this work!  If the constraints
        !          1009:      allow only constants, but the predicate allows something else,
        !          1010:      the compiler will crash when that case arises.
        !          1011: 
        !          1012: `(match_dup N)'
        !          1013:      This expression is also a placeholder for operand number N.  It
        !          1014:      is used when the operand needs to appear more than once in the
        !          1015:      insn.
        !          1016: 
        !          1017:      In construction, `match_dup' behaves exactly like
        !          1018:      `match_operand': the operand is substituted into the insn being
        !          1019:      constructed.  But in matching, `match_dup' behaves differently. 
        !          1020:      It assumes that operand number N has already been determined by
        !          1021:      a `match_operand' appearing earlier in the recognition template,
        !          1022:      and it matches only an identical-looking expression.
        !          1023: 
        !          1024: `(address (match_operand:M N "address_operand" ""))'
        !          1025:      This complex of expressions is a placeholder for an operand
        !          1026:      number N in a ``load address'' instruction: an operand which
        !          1027:      specifies a memory location in the usual way, but for which the
        !          1028:      actual operand value used is the address of the location, not
        !          1029:      the contents of the location.
        !          1030: 
        !          1031:      `address' expressions never appear in RTL code, only in machine
        !          1032:      descriptions.  And they are used only in machine descriptions
        !          1033:      that do not use the operand constraint feature.  When operand
        !          1034:      constraints are in use, the letter `p' in the constraint serves
        !          1035:      this purpose.
        !          1036: 
        !          1037:      M is the machine mode of the *memory location being addressed*,
        !          1038:      not the machine mode of the address itself.  That mode is always
        !          1039:      the same on a given target machine (it is `Pmode', which
        !          1040:      normally is `SImode'), so there is no point in mentioning it;
        !          1041:      thus, no machine mode is written in the `address' expression. 
        !          1042:      If some day support is added for machines in which addresses of
        !          1043:      different kinds of objects appear differently or are used
        !          1044:      differently (such as the PDP-10), different formats would
        !          1045:      perhaps need different machine modes and these modes might be
        !          1046:      written in the `address' expression.
        !          1047: 
        !          1048: 
        !          1049: 
        !          1050: File: gcc.info,  Node: Output Template,  Next: Output Statement,  Prev: RTL Template,  Up: Machine Desc
        !          1051: 
        !          1052: Output Templates and Operand Substitution
        !          1053: =========================================
        !          1054: 
        !          1055: The "output template" is a string which specifies how to output the
        !          1056: assembler code for an instruction pattern.  Most of the template is a
        !          1057: fixed string which is output literally.  The character `%' is used to
        !          1058: specify where to substitute an operand; it can also be used to
        !          1059: identify places different variants of the assembler require different
        !          1060: syntax.
        !          1061: 
        !          1062: In the simplest case, a `%' followed by a digit N says to output
        !          1063: operand N at that point in the string.
        !          1064: 
        !          1065: `%' followed by a letter and a digit says to output an operand in an
        !          1066: alternate fashion.  Four letters have standard, built-in meanings
        !          1067: described below.  The machine description macro `PRINT_OPERAND' can
        !          1068: define additional letters with nonstandard meanings.
        !          1069: 
        !          1070: `%cDIGIT' can be used to substitute an operand that is a constant
        !          1071: value without the syntax that normally indicates an immediate operand.
        !          1072: 
        !          1073: `%nDIGIT' is like `%cDIGIT' except that the value of the constant is
        !          1074: negated before printing.
        !          1075: 
        !          1076: `%aDIGIT' can be used to substitute an operand as if it were a memory
        !          1077: reference, with the actual operand treated as the address.  This may
        !          1078: be useful when outputting a ``load address'' instruction, because
        !          1079: often the assembler syntax for such an instruction requires you to
        !          1080: write the operand as if it were a memory reference.
        !          1081: 
        !          1082: `%lDIGIT' is used to substitute a `label_ref' into a jump instruction.
        !          1083: 
        !          1084: `%' followed by a punctuation character specifies a substitution that
        !          1085: does not use an operand.  Only one case is standard: `%%' outputs a
        !          1086: `%' into the assembler code.  Other nonstandard cases can be defined
        !          1087: in the `PRINT_OPERAND' macro.
        !          1088: 
        !          1089: The template may generate multiple assembler instructions.  Write the
        !          1090: text for the instructions, with `\;' between them.
        !          1091: 
        !          1092: When the RTL contains two operand which are required by constraint to
        !          1093: match each other, the output template must refer only to the
        !          1094: lower-numbered operand.  Matching operands are not always identical,
        !          1095: and the rest of the compiler arranges to put the proper RTL
        !          1096: expression for printing into the lower-numbered operand.
        !          1097: 
        !          1098: One use of nonstandard letters or punctuation following `%' is to
        !          1099: distinguish between different assembler languages for the same
        !          1100: machine; for example, Motorola syntax versus MIT syntax for the
        !          1101: 68000.  Motorola syntax requires periods in most opcode names, while
        !          1102: MIT syntax does not.  For example, the opcode `movel' in MIT syntax
        !          1103: is `move.l' in Motorola syntax.  The same file of patterns is used
        !          1104: for both kinds of output syntax, but the character sequence `%.' is
        !          1105: used in each place where Motorola syntax wants a period.  The
        !          1106: `PRINT_OPERAND' macro for Motorola syntax defines the sequence to
        !          1107: output a period; the macro for MIT syntax defines it to do nothing.
        !          1108: 
        !          1109: 
        !          1110: 
        !          1111: File: gcc.info,  Node: Output Statement,  Next: Constraints,  Prev: Output Template,  Up: Machine Desc
        !          1112: 
        !          1113: C Statements for Generating Assembler Output
        !          1114: ============================================
        !          1115: 
        !          1116: Often a single fixed template string cannot produce correct and
        !          1117: efficient assembler code for all the cases that are recognized by a
        !          1118: single instruction pattern.  For example, the opcodes may depend on
        !          1119: the kinds of operands; or some unfortunate combinations of operands
        !          1120: may require extra machine instructions.
        !          1121: 
        !          1122: If the output control string starts with a `*', then it is not an
        !          1123: output template but rather a piece of C program that should compute a
        !          1124: template.  It should execute a `return' statement to return the
        !          1125: template-string you want.  Most such templates use C string literals,
        !          1126: which require doublequote characters to delimit them.  To include
        !          1127: these doublequote characters in the string, prefix each one with `\'.
        !          1128: 
        !          1129: The operands may be found in the array `operands', whose C data type
        !          1130: is `rtx []'.
        !          1131: 
        !          1132: It is possible to output an assembler instruction and then go on to
        !          1133: output or compute more of them, using the subroutine
        !          1134: `output_asm_insn'.  This receives two arguments: a template-string
        !          1135: and a vector of operands.  The vector may be `operands', or it may be
        !          1136: another array of `rtx' that you declare locally and initialize
        !          1137: yourself.
        !          1138: 
        !          1139: When an insn pattern has multiple alternatives in its constraints,
        !          1140: often the appearance of the assembler code determined mostly by which
        !          1141: alternative was matched.  When this is so, the C code can test the
        !          1142: variable `which_alternative', which is the ordinal number of the
        !          1143: alternative that was actually satisfied (0 for the first, 1 for the
        !          1144: second alternative, etc.).
        !          1145: 
        !          1146: For example, suppose there are two opcodes for storing zero, `clrreg'
        !          1147: for registers and `clrmem' for memory locations.  Here is how a
        !          1148: pattern could use `which_alternative' to choose between them:
        !          1149: 
        !          1150:      (define_insn ""
        !          1151:        [(set (match_operand:SI 0 "general_operand" "r,m")
        !          1152:              (const_int 0))]
        !          1153:        ""
        !          1154:        "*
        !          1155:        return (which_alternative == 0
        !          1156:                ? \"clrreg %0\" : \"clrmem %0\");
        !          1157:        ")
        !          1158: 
        !          1159: 
        !          1160: 
        !          1161: File: gcc.info,  Node: Constraints,  Next: Standard Names,  Prev: Output Statement,  Up: Machine Desc
        !          1162: 
        !          1163: Operand Constraints
        !          1164: ===================
        !          1165: 
        !          1166: Each `match_operand' in an instruction pattern can specify a
        !          1167: constraint for the type of operands allowed.  Constraints can say
        !          1168: whether an operand may be in a register, and which kinds of register;
        !          1169: whether the operand can be a memory reference, and which kinds of
        !          1170: address; whether the operand may be an immediate constant, and which
        !          1171: possible values it may have.  Constraints can also require two
        !          1172: operands to match.
        !          1173: 
        !          1174: * Menu:
        !          1175: 
        !          1176: * Simple Constraints::  Basic use of constraints.
        !          1177: * Multi-Alternative::   When an insn has two alternative constraint-patterns.
        !          1178: * Class Preferences::   Constraints guide which hard register to put things in.
        !          1179: * Modifiers::           More precise control over effects of constraints.
        !          1180: * No Constraints::      Describing a clean machine without constraints.
        !          1181: 
        !          1182:  

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