Return to gcc.info-8 CVS log

Up to [GCC 2.x] / gcc

Annotation of gcc/gcc.info-8, revision 1.1.1.2

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

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