Return to gcc.info-10 CVS log

Up to [GCC 2.x] / gcc

Annotation of gcc/gcc.info-10, 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: Simple Constraints,  Next: Multi-Alternative,  Prev: Constraints,  Up: Constraints
        !            28: 
        !            29: Simple Constraints
        !            30: ------------------
        !            31: 
        !            32:    The simplest kind of constraint is a string full of letters, each of
        !            33: which describes one kind of operand that is permitted.  Here are the
        !            34: letters that are allowed:
        !            35: 
        !            36: `m'
        !            37:      A memory operand is allowed, with any kind of address that the
        !            38:      machine supports in general.
        !            39: 
        !            40: `o'
        !            41:      A memory operand is allowed, but only if the address is
        !            42:      "offsettable".  This means that adding a small integer (actually,
        !            43:      the width in bytes of the operand, as determined by its machine
        !            44:      mode) may be added to the address and the result is also a valid
        !            45:      memory address.
        !            46: 
        !            47:      For example, an address which is constant is offsettable; so is an
        !            48:      address that is the sum of a register and a constant (as long as a
        !            49:      slightly larger constant is also within the range of
        !            50:      address-offsets supported by the machine); but an autoincrement
        !            51:      or autodecrement address is not offsettable.  More complicated
        !            52:      indirect/indexed addresses may or may not be offsettable
        !            53:      depending on the other addressing modes that the machine supports.
        !            54: 
        !            55:      Note that in an output operand which can be matched by another
        !            56:      operand, the constraint letter `o' is valid only when accompanied
        !            57:      by both `<' (if the target machine has predecrement addressing)
        !            58:      and `>' (if the target machine has preincrement addressing).
        !            59: 
        !            60: `V'
        !            61:      A memory operand that is not offsettable.  In other words,
        !            62:      anything that would fit the `m' constraint but not the `o'
        !            63:      constraint.
        !            64: 
        !            65: `<'
        !            66:      A memory operand with autodecrement addressing (either
        !            67:      predecrement or postdecrement) is allowed.
        !            68: 
        !            69: `>'
        !            70:      A memory operand with autoincrement addressing (either
        !            71:      preincrement or postincrement) is allowed.
        !            72: 
        !            73: `r'
        !            74:      A register operand is allowed provided that it is in a general
        !            75:      register.
        !            76: 
        !            77: `d', `a', `f', ...
        !            78:      Other letters can be defined in machine-dependent fashion to
        !            79:      stand for particular classes of registers.  `d', `a' and `f' are
        !            80:      defined on the 68000/68020 to stand for data, address and floating
        !            81:      point registers.
        !            82: 
        !            83: `i'
        !            84:      An immediate integer operand (one with constant value) is allowed. 
        !            85:      This includes symbolic constants whose values will be known only
        !            86:      at assembly time.
        !            87: 
        !            88: `n'
        !            89:      An immediate integer operand with a known numeric value is
        !            90:      allowed.  Many systems cannot support assembly-time constants for
        !            91:      operands less than a word wide.  Constraints for these operands
        !            92:      should use `n' rather than `i'.
        !            93: 
        !            94: `I', `J', `K', ... `P'
        !            95:      Other letters in the range `I' through `P' may be defined in a
        !            96:      machine-dependent fashion to permit immediate integer operands
        !            97:      with explicit integer values in specified ranges.  For example,
        !            98:      on the 68000, `I' is defined to stand for the range of values 1
        !            99:      to 8.  This is the range permitted as a shift count in the shift
        !           100:      instructions.
        !           101: 
        !           102: `E'
        !           103:      An immediate floating operand (expression code `const_double') is
        !           104:      allowed, but only if the target floating point format is the same
        !           105:      as that of the host machine (on which the compiler is running).
        !           106: 
        !           107: `F'
        !           108:      An immediate floating operand (expression code `const_double') is
        !           109:      allowed.
        !           110: 
        !           111: `G', `H'
        !           112:      `G' and `H' may be defined in a machine-dependent fashion to
        !           113:      permit immediate floating operands in particular ranges of values.
        !           114: 
        !           115: `s'
        !           116:      An immediate integer operand whose value is not an explicit
        !           117:      integer is allowed.
        !           118: 
        !           119:      This might appear strange; if an insn allows a constant operand
        !           120:      with a value not known at compile time, it certainly must allow
        !           121:      any known value.  So why use `s' instead of `i'?  Sometimes it
        !           122:      allows better code to be generated.
        !           123: 
        !           124:      For example, on the 68000 in a fullword instruction it is
        !           125:      possible to use an immediate operand; but if the immediate value
        !           126:      is between -128 and 127, better code results from loading the
        !           127:      value into a register and using the register.  This is because
        !           128:      the load into the register can be done with a `moveq'
        !           129:      instruction.  We arrange for this to happen by defining the
        !           130:      letter `K' to mean "any integer outside the range -128 to 127",
        !           131:      and then specifying `Ks' in the operand constraints.
        !           132: 
        !           133: `g'
        !           134:      Any register, memory or immediate integer operand is allowed,
        !           135:      except for registers that are not general registers.
        !           136: 
        !           137: `X'
        !           138:      Any operand whatsoever is allowed, even if it does not satisfy
        !           139:      `general_operand'.  This is normally used in the constraint of a
        !           140:      `match_scratch' when certain alternatives will not actually
        !           141:      require a scratch register.
        !           142: 
        !           143: `0', `1', `2', ... `9'
        !           144:      An operand that matches the specified operand number is allowed. 
        !           145:      If a digit is used together with letters within the same
        !           146:      alternative, the digit should come last.
        !           147: 
        !           148:      This is called a "matching constraint" and what it really means is
        !           149:      that the assembler has only a single operand that fills two roles
        !           150:      considered separate in the RTL insn.  For example, an add insn
        !           151:      has two input operands and one output operand in the RTL, but on
        !           152:      most machines an add instruction really has only two operands,
        !           153:      one of them an input-output operand.
        !           154: 
        !           155:      Matching constraints work only in circumstances like that add
        !           156:      insn.  More precisely, the two operands that match must include
        !           157:      one input-only operand and one output-only operand.  Moreover,
        !           158:      the digit must be a smaller number than the number of the operand
        !           159:      that uses it in the constraint.
        !           160: 
        !           161:      For operands to match in a particular case usually means that they
        !           162:      are identical-looking RTL expressions.  But in a few special cases
        !           163:      specific kinds of dissimilarity are allowed.  For example, `*x'
        !           164:      as an input operand will match `*x++' as an output operand.  For
        !           165:      proper results in such cases, the output template should always
        !           166:      use the output-operand's number when printing the operand.
        !           167: 
        !           168: `p'
        !           169:      An operand that is a valid memory address is allowed.  This is
        !           170:      for "load address" and "push address" instructions.
        !           171: 
        !           172:      `p' in the constraint must be accompanied by `address_operand' as
        !           173:      the predicate in the `match_operand'.  This predicate interprets
        !           174:      the mode specified in the `match_operand' as the mode of the
        !           175:      memory reference for which the address would be valid.
        !           176: 
        !           177: `Q', `R', `S', ... `U'
        !           178:      Letters in the range `Q' through `U' may be defined in a
        !           179:      machine-dependent fashion to stand for arbitrary operand types. 
        !           180:      The machine description macro `EXTRA_CONSTRAINT' is passed the
        !           181:      operand as its first argument and the constraint letter as its
        !           182:      second operand.
        !           183: 
        !           184:      A typical use for this would be to distinguish certain types of
        !           185:      memory references that affect other insn operands.
        !           186: 
        !           187:      Do not define these constraint letters to accept register
        !           188:      references (`reg'); the reload pass does not expect this and
        !           189:      would not handle it properly.
        !           190: 
        !           191:    In order to have valid assembler code, each operand must satisfy
        !           192: its constraint.  But a failure to do so does not prevent the pattern
        !           193: from applying to an insn.  Instead, it directs the compiler to modify
        !           194: the code so that the constraint will be satisfied.  Usually this is
        !           195: done by copying an operand into a register.
        !           196: 
        !           197:    Contrast, therefore, the two instruction patterns that follow:
        !           198: 
        !           199:      (define_insn ""
        !           200:        [(set (match_operand:SI 0 "general_operand" "r")
        !           201:              (plus:SI (match_dup 0)
        !           202:                       (match_operand:SI 1 "general_operand" "r")))]
        !           203:        ""
        !           204:        "...")
        !           205: 
        !           206: which has two operands, one of which must appear in two places, and
        !           207: 
        !           208:      (define_insn ""
        !           209:        [(set (match_operand:SI 0 "general_operand" "r")
        !           210:              (plus:SI (match_operand:SI 1 "general_operand" "0")
        !           211:                       (match_operand:SI 2 "general_operand" "r")))]
        !           212:        ""
        !           213:        "...")
        !           214: 
        !           215: which has three operands, two of which are required by a constraint to
        !           216: be identical.  If we are considering an insn of the form
        !           217: 
        !           218:      (insn N PREV NEXT
        !           219:        (set (reg:SI 3)
        !           220:             (plus:SI (reg:SI 6) (reg:SI 109)))
        !           221:        ...)
        !           222: 
        !           223: the first pattern would not apply at all, because this insn does not
        !           224: contain two identical subexpressions in the right place.  The pattern
        !           225: would say, "That does not look like an add instruction; try other
        !           226: patterns." The second pattern would say, "Yes, that's an add
        !           227: instruction, but there is something wrong with it."  It would direct
        !           228: the reload pass of the compiler to generate additional insns to make
        !           229: the constraint true.  The results might look like this:
        !           230: 
        !           231:      (insn N2 PREV N
        !           232:        (set (reg:SI 3) (reg:SI 6))
        !           233:        ...)
        !           234:      
        !           235:      (insn N N2 NEXT
        !           236:        (set (reg:SI 3)
        !           237:             (plus:SI (reg:SI 3) (reg:SI 109)))
        !           238:        ...)
        !           239: 
        !           240:    It is up to you to make sure that each operand, in each pattern, has
        !           241: constraints that can handle any RTL expression that could be present
        !           242: for that operand.  (When multiple alternatives are in use, each
        !           243: pattern must, for each possible combination of operand expressions,
        !           244: have at least one alternative which can handle that combination of
        !           245: operands.)  The constraints don't need to *allow* any possible
        !           246: operand--when this is the case, they do not constrain--but they must
        !           247: at least point the way to reloading any possible operand so that it
        !           248: will fit.
        !           249: 
        !           250:    * If the constraint accepts whatever operands the predicate permits,
        !           251:      there is no problem: reloading is never necessary for this
        !           252:      operand.
        !           253: 
        !           254:      For example, an operand whose constraints permit everything except
        !           255:      registers is safe provided its predicate rejects registers.
        !           256: 
        !           257:      An operand whose predicate accepts only constant values is safe
        !           258:      provided its constraints include the letter `i'.  If any possible
        !           259:      constant value is accepted, then nothing less than `i' will do;
        !           260:      if the predicate is more selective, then the constraints may also
        !           261:      be more selective.
        !           262: 
        !           263:    * Any operand expression can be reloaded by copying it into a
        !           264:      register.  So if an operand's constraints allow some kind of
        !           265:      register, it is certain to be safe.  It need not permit all
        !           266:      classes of registers; the compiler knows how to copy a register
        !           267:      into another register of the proper class in order to make an
        !           268:      instruction valid.
        !           269: 
        !           270:    * A nonoffsettable memory reference can be reloaded by copying the
        !           271:      address into a register.  So if the constraint uses the letter
        !           272:      `o', all memory references are taken care of.
        !           273: 
        !           274:    * A constant operand can be reloaded by allocating space in memory
        !           275:      to hold it as preinitialized data.  Then the memory reference can
        !           276:      be used in place of the constant.  So if the constraint uses the
        !           277:      letters `o' or `m', constant operands are not a problem.
        !           278: 
        !           279:    * If the constraint permits a constant and a pseudo register used
        !           280:      in an insn was not allocated to a hard register and is equivalent
        !           281:      to a constant, the register will be replaced with the constant. 
        !           282:      If the predicate does not permit a constant and the insn is
        !           283:      re-recognized for some reason, the compiler will crash.  Thus the
        !           284:      predicate must always recognize any objects allowed by the
        !           285:      constraint.
        !           286: 
        !           287:    If the operand's predicate can recognize registers, but the
        !           288: constraint does not permit them, it can make the compiler crash.  When
        !           289: this operand happens to be a register, the reload pass will be
        !           290: stymied, because it does not know how to copy a register temporarily
        !           291: into memory.
        !           292: 
        !           293: 
        !           294: File: gcc.info,  Node: Multi-Alternative,  Next: Class Preferences,  Prev: Simple Constraints,  Up: Constraints
        !           295: 
        !           296: Multiple Alternative Constraints
        !           297: --------------------------------
        !           298: 
        !           299:    Sometimes a single instruction has multiple alternative sets of
        !           300: possible operands.  For example, on the 68000, a logical-or
        !           301: instruction can combine register or an immediate value into memory, or
        !           302: it can combine any kind of operand into a register; but it cannot
        !           303: combine one memory location into another.
        !           304: 
        !           305:    These constraints are represented as multiple alternatives.  An
        !           306: alternative can be described by a series of letters for each operand. 
        !           307: The overall constraint for an operand is made from the letters for
        !           308: this operand from the first alternative, a comma, the letters for this
        !           309: operand from the second alternative, a comma, and so on until the last
        !           310: alternative.  Here is how it is done for fullword logical-or on the
        !           311: 68000:
        !           312: 
        !           313:      (define_insn "iorsi3"
        !           314:        [(set (match_operand:SI 0 "general_operand" "=m,d")
        !           315:              (ior:SI (match_operand:SI 1 "general_operand" "%0,0")
        !           316:                      (match_operand:SI 2 "general_operand" "dKs,dmKs")))]
        !           317:        ...)
        !           318: 
        !           319:    The first alternative has `m' (memory) for operand 0, `0' for
        !           320: operand 1 (meaning it must match operand 0), and `dKs' for operand 2. 
        !           321: The second alternative has `d' (data register) for operand 0, `0' for
        !           322: operand 1, and `dmKs' for operand 2.  The `=' and `%' in the
        !           323: constraints apply to all the alternatives; their meaning is explained
        !           324: in the next section (*note Class Preferences::.).
        !           325: 
        !           326:    If all the operands fit any one alternative, the instruction is
        !           327: valid.  Otherwise, for each alternative, the compiler counts how many
        !           328: instructions must be added to copy the operands so that that
        !           329: alternative applies.  The alternative requiring the least copying is
        !           330: chosen.  If two alternatives need the same amount of copying, the one
        !           331: that comes first is chosen.  These choices can be altered with the `?'
        !           332: and `!' characters:
        !           333: 
        !           334: `?'
        !           335:      Disparage slightly the alternative that the `?' appears in, as a
        !           336:      choice when no alternative applies exactly.  The compiler regards
        !           337:      this alternative as one unit more costly for each `?' that appears
        !           338:      in it.
        !           339: 
        !           340: `!'
        !           341:      Disparage severely the alternative that the `!' appears in.  This
        !           342:      alternative can still be used if it fits without reloading, but
        !           343:      if reloading is needed, some other alternative will be used.
        !           344: 
        !           345:    When an insn pattern has multiple alternatives in its constraints,
        !           346: often the appearance of the assembler code is determined mostly by
        !           347: which alternative was matched.  When this is so, the C code for
        !           348: writing the assembler code can use the variable `which_alternative',
        !           349: which is the ordinal number of the alternative that was actually
        !           350: satisfied (0 for the first, 1 for the second alternative, etc.). 
        !           351: *Note Output Statement::.
        !           352: 
        !           353: 
        !           354: File: gcc.info,  Node: Class Preferences,  Next: Modifiers,  Prev: Multi-Alternative,  Up: Constraints
        !           355: 
        !           356: Register Class Preferences
        !           357: --------------------------
        !           358: 
        !           359:    The operand constraints have another function: they enable the
        !           360: compiler to decide which kind of hardware register a pseudo register
        !           361: is best allocated to.  The compiler examines the constraints that
        !           362: apply to the insns that use the pseudo register, looking for the
        !           363: machine-dependent letters such as `d' and `a' that specify classes of
        !           364: registers.  The pseudo register is put in whichever class gets the
        !           365: most "votes".  The constraint letters `g' and `r' also vote: they vote
        !           366: in favor of a general register.  The machine description says which
        !           367: registers are considered general.
        !           368: 
        !           369:    Of course, on some machines all registers are equivalent, and no
        !           370: register classes are defined.  Then none of this complexity is
        !           371: relevant.
        !           372: 
        !           373: 
        !           374: File: gcc.info,  Node: Modifiers,  Next: No Constraints,  Prev: Class Preferences,  Up: Constraints
        !           375: 
        !           376: Constraint Modifier Characters
        !           377: ------------------------------
        !           378: 
        !           379: `='
        !           380:      Means that this operand is write-only for this instruction: the
        !           381:      previous value is discarded and replaced by output data.
        !           382: 
        !           383: `+'
        !           384:      Means that this operand is both read and written by the
        !           385:      instruction.
        !           386: 
        !           387:      When the compiler fixes up the operands to satisfy the
        !           388:      constraints, it needs to know which operands are inputs to the
        !           389:      instruction and which are outputs from it.  `=' identifies an
        !           390:      output; `+' identifies an operand that is both input and output;
        !           391:      all other operands are assumed to be input only.
        !           392: 
        !           393: `&'
        !           394:      Means (in a particular alternative) that this operand is written
        !           395:      before the instruction is finished using the input operands. 
        !           396:      Therefore, this operand may not lie in a register that is used as
        !           397:      an input operand or as part of any memory address.
        !           398: 
        !           399:      `&' applies only to the alternative in which it is written.  In
        !           400:      constraints with multiple alternatives, sometimes one alternative
        !           401:      requires `&' while others do not.  See, for example, the `movdf'
        !           402:      insn of the 68000.
        !           403: 
        !           404:      `&' does not obviate the need to write `='.
        !           405: 
        !           406: `%'
        !           407:      Declares the instruction to be commutative for this operand and
        !           408:      the following operand.  This means that the compiler may
        !           409:      interchange the two operands if that is the cheapest way to make
        !           410:      all operands fit the constraints.  This is often used in patterns
        !           411:      for addition instructions that really have only two operands: the
        !           412:      result must go in one of the arguments.  Here for example, is how
        !           413:      the 68000 halfword-add instruction is defined:
        !           414: 
        !           415:           (define_insn "addhi3"
        !           416:             [(set (match_operand:HI 0 "general_operand" "=m,r")
        !           417:                (plus:HI (match_operand:HI 1 "general_operand" "%0,0")
        !           418:                         (match_operand:HI 2 "general_operand" "di,g")))]
        !           419:             ...)
        !           420: 
        !           421: `#'
        !           422:      Says that all following characters, up to the next comma, are to
        !           423:      be ignored as a constraint.  They are significant only for
        !           424:      choosing register preferences.
        !           425: 
        !           426: `*'
        !           427:      Says that the following character should be ignored when choosing
        !           428:      register preferences.  `*' has no effect on the meaning of the
        !           429:      constraint as a constraint, and no effect on reloading.
        !           430: 
        !           431:      Here is an example: the 68000 has an instruction to sign-extend a
        !           432:      halfword in a data register, and can also sign-extend a value by
        !           433:      copying it into an address register.  While either kind of
        !           434:      register is acceptable, the constraints on an address-register
        !           435:      destination are less strict, so it is best if register allocation
        !           436:      makes an address register its goal.  Therefore, `*' is used so
        !           437:      that the `d' constraint letter (for data register) is ignored
        !           438:      when computing register preferences.
        !           439: 
        !           440:           (define_insn "extendhisi2"
        !           441:             [(set (match_operand:SI 0 "general_operand" "=*d,a")
        !           442:                   (sign_extend:SI
        !           443:                    (match_operand:HI 1 "general_operand" "0,g")))]
        !           444:             ...)
        !           445: 
        !           446: 
        !           447: File: gcc.info,  Node: No Constraints,  Prev: Modifiers,  Up: Constraints
        !           448: 
        !           449: Not Using Constraints
        !           450: ---------------------
        !           451: 
        !           452:    Some machines are so clean that operand constraints are not
        !           453: required.  For example, on the Vax, an operand valid in one context is
        !           454: valid in any other context.  On such a machine, every operand
        !           455: constraint would be `g', excepting only operands of "load address"
        !           456: instructions which are written as if they referred to a memory
        !           457: location's contents but actual refer to its address.  They would have
        !           458: constraint `p'.
        !           459: 
        !           460:    For such machines, instead of writing `g' and `p' for all the
        !           461: constraints, you can choose to write a description with empty
        !           462: constraints.  Then you write `""' for the constraint in every
        !           463: `match_operand'.  Address operands are identified by writing an
        !           464: `address' expression around the `match_operand', not by their
        !           465: constraints.
        !           466: 
        !           467:    When the machine description has just empty constraints, certain
        !           468: parts of compilation are skipped, making the compiler faster.  However,
        !           469: few machines actually do not need constraints; all machine descriptions
        !           470: now in existence use constraints.
        !           471: 
        !           472: 
1.1       root      473: File: gcc.info,  Node: Standard Names,  Next: Pattern Ordering,  Prev: Constraints,  Up: Machine Desc
                    474: 
                    475: Standard Names for Patterns Used in Generation
                    476: ==============================================
                    477: 
                    478:    Here is a table of the instruction names that are meaningful in the
                    479: RTL generation pass of the compiler.  Giving one of these names to an
                    480: instruction pattern tells the RTL generation pass that it can use the
                    481: pattern in to accomplish a certain task.
                    482: 
                    483: `movM'
                    484:      Here M stands for a two-letter machine mode name, in lower case. 
                    485:      This instruction pattern moves data with that machine mode from
                    486:      operand 1 to operand 0.  For example, `movsi' moves full-word
                    487:      data.
                    488: 
                    489:      If operand 0 is a `subreg' with mode M of a register whose own
                    490:      mode is wider than M, the effect of this instruction is to store
                    491:      the specified value in the part of the register that corresponds
                    492:      to mode M.  The effect on the rest of the register is undefined.
                    493: 
                    494:      This class of patterns is special in several ways.  First of all,
                    495:      each of these names *must* be defined, because there is no other
                    496:      way to copy a datum from one place to another.
                    497: 
                    498:      Second, these patterns are not used solely in the RTL generation
                    499:      pass.  Even the reload pass can generate move insns to copy
                    500:      values from stack slots into temporary registers.  When it does
                    501:      so, one of the operands is a hard register and the other is an
                    502:      operand that can need to be reloaded into a register.
                    503: 
                    504:      Therefore, when given such a pair of operands, the pattern must
                    505:      generate RTL which needs no reloading and needs no temporary
                    506:      registers--no registers other than the operands.  For example, if
                    507:      you support the pattern with a `define_expand', then in such a
                    508:      case the `define_expand' mustn't call `force_reg' or any other
                    509:      such function which might generate new pseudo registers.
                    510: 
                    511:      This requirement exists even for subword modes on a RISC machine
                    512:      where fetching those modes from memory normally requires several
                    513:      insns and some temporary registers.  Look in `spur.md' to see how
                    514:      the requirement can be satisfied.
                    515: 
                    516:      During reload a memory reference with an invalid address may be
                    517:      passed as an operand.  Such an address will be replaced with a
                    518:      valid address later in the reload pass.  In this case, nothing
                    519:      may be done with the address except to use it as it stands.  If
                    520:      it is copied, it will not be replaced with a valid address.  No
                    521:      attempt should be made to make such an address into a valid
                    522:      address and no routine (such as `change_address') that will do so
                    523:      may be called.  Note that `general_operand' will fail when
                    524:      applied to such an address.
                    525: 
                    526:      The global variable `reload_in_progress' (which must be explicitly
                    527:      declared if required) can be used to determine whether such
                    528:      special handling is required.
                    529: 
                    530:      The variety of operands that have reloads depends on the rest of
                    531:      the machine description, but typically on a RISC machine these
                    532:      can only be pseudo registers that did not get hard registers,
                    533:      while on other machines explicit memory references will get
                    534:      optional reloads.
                    535: 
                    536:      If a scratch register is required to move an object to or from
                    537:      memory, it can be allocated using `gen_reg_rtx' prior to reload. 
                    538:      But this is impossible during and after reload.  If there are
                    539:      cases needing scratch registers after reload, you must define
                    540:      `SECONDARY_INPUT_RELOAD_CLASS' and/or
                    541:      `SECONDARY_OUTPUT_RELOAD_CLASS' to detect them, and provide
                    542:      patterns `reload_inM' or `reload_outM' to handle them.  *Note
                    543:      Register Classes::.
                    544: 
                    545:      The constraints on a `moveM' must permit moving any hard register
                    546:      to any other hard register provided that `HARD_REGNO_MODE_OK'
                    547:      permits mode M in both registers and `REGISTER_MOVE_COST' applied
                    548:      to their classes returns a value of 2.
                    549: 
                    550:      It is obligatory to support floating point `moveM' instructions
                    551:      into and out of any registers that can hold fixed point values,
                    552:      because unions and structures (which have modes `SImode' or
                    553:      `DImode') can be in those registers and they may have floating
                    554:      point members.
                    555: 
                    556:      There may also be a need to support fixed point `moveM'
                    557:      instructions in and out of floating point registers. 
                    558:      Unfortunately, I have forgotten why this was so, and I don't know
                    559:      whether it is still true.  If `HARD_REGNO_MODE_OK' rejects fixed
                    560:      point values in floating point registers, then the constraints of
                    561:      the fixed point `moveM' instructions must be designed to avoid
                    562:      ever trying to reload into a floating point register.
                    563: 
                    564: `reload_inM'
                    565: `reload_outM'
                    566:      Like `movM', but used when a scratch register is required to move
                    567:      between operand 0 and operand 1.  Operand 2 describes the scratch
                    568:      register.  See the discussion of the `SECONDARY_RELOAD_CLASS'
                    569:      macro in *note Register Classes::..
                    570: 
                    571: `movstrictM'
                    572:      Like `movM' except that if operand 0 is a `subreg' with mode M of
                    573:      a register whose natural mode is wider, the `movstrictM'
                    574:      instruction is guaranteed not to alter any of the register except
                    575:      the part which belongs to mode M.
                    576: 
                    577: `addM3'
                    578:      Add operand 2 and operand 1, storing the result in operand 0. 
                    579:      All operands must have mode M.  This can be used even on
                    580:      two-address machines, by means of constraints requiring operands
                    581:      1 and 0 to be the same location.
                    582: 
                    583: `subM3', `mulM3'
                    584: `divM3', `udivM3', `modM3', `umodM3'
                    585: `sminM3', `smaxM3', `uminM3', `umaxM3'
                    586: `andM3', `iorM3', `xorM3'
                    587:      Similar, for other arithmetic operations.
                    588: 
                    589: `mulhisi3'
                    590:      Multiply operands 1 and 2, which have mode `HImode', and store a
                    591:      `SImode' product in operand 0.
                    592: 
                    593: `mulqihi3', `mulsidi3'
                    594:      Similar widening-multiplication instructions of other widths.
                    595: 
                    596: `umulqihi3', `umulhisi3', `umulsidi3'
                    597:      Similar widening-multiplication instructions that do unsigned
                    598:      multiplication.
                    599: 
                    600: `divmodM4'
                    601:      Signed division that produces both a quotient and a remainder. 
                    602:      Operand 1 is divided by operand 2 to produce a quotient stored in
                    603:      operand 0 and a remainder stored in operand 3.
                    604: 
                    605:      For machines with an instruction that produces both a quotient
                    606:      and a remainder, provide a pattern for `divmodM4' but do not
                    607:      provide patterns for `divM3' and `modM3'.  This allows
                    608:      optimization in the relatively common case when both the quotient
                    609:      and remainder are computed.
                    610: 
                    611:      If an instruction that just produces a quotient or just a
                    612:      remainder exists and is more efficient than the instruction that
                    613:      produces both, write the output routine of `divmodM4' to call
                    614:      `find_reg_note' and look for a `REG_UNUSED' note on the quotient
                    615:      or remainder and generate the appropriate instruction.
                    616: 
                    617: `udivmodM4'
                    618:      Similar, but does unsigned division.
                    619: 
                    620: `ashlM3'
                    621:      Arithmetic-shift operand 1 left by a number of bits specified by
                    622:      operand 2, and store the result in operand 0.  Operand 2 has mode
                    623:      `SImode', not mode M.
                    624: 
                    625: `ashrM3', `lshlM3', `lshrM3', `rotlM3', `rotrM3'
                    626:      Other shift and rotate instructions.
                    627: 
                    628:      Logical and arithmetic left shift are the same.  Machines that do
                    629:      not allow negative shift counts often have only one instruction
                    630:      for shifting left.  On such machines, you should define a pattern
                    631:      named `ashlM3' and leave `lshlM3' undefined.
                    632: 
                    633: `negM2'
                    634:      Negate operand 1 and store the result in operand 0.
                    635: 
                    636: `absM2'
                    637:      Store the absolute value of operand 1 into operand 0.
                    638: 
                    639: `sqrtM2'
                    640:      Store the square root of operand 1 into operand 0.
                    641: 
                    642: `ffsM2'
                    643:      Store into operand 0 one plus the index of the least significant
                    644:      1-bit of operand 1.  If operand 1 is zero, store zero.  M is the
                    645:      mode of operand 0; operand 1's mode is specified by the
                    646:      instruction pattern, and the compiler will convert the operand to
                    647:      that mode before generating the instruction.
                    648: 
                    649: `one_cmplM2'
                    650:      Store the bitwise-complement of operand 1 into operand 0.
                    651: 
                    652: `cmpM'
                    653:      Compare operand 0 and operand 1, and set the condition codes. 
                    654:      The RTL pattern should look like this:
                    655: 
                    656:           (set (cc0) (compare (match_operand:M 0 ...)
                    657:                               (match_operand:M 1 ...)))
                    658: 
                    659: `tstM'
                    660:      Compare operand 0 against zero, and set the condition codes.  The
                    661:      RTL pattern should look like this:
                    662: 
                    663:           (set (cc0) (match_operand:M 0 ...))
                    664: 
                    665:      `tstM' patterns should not be defined for machines that do not
                    666:      use `(cc0)'.  Doing so would confuse the optimizer since it would
                    667:      no longer be clear which `set' operations were comparisons.  The
                    668:      `cmpM' patterns should be used instead.
                    669: 
                    670: `movstrM'
                    671:      Block move instruction.  The addresses of the destination and
                    672:      source strings are the first two operands, and both are in mode
                    673:      `Pmode'.  The number of bytes to move is the third operand, in
                    674:      mode M.
                    675: 
                    676:      The fourth operand is the known shared alignment of the source and
                    677:      destination, in the form of a `const_int' rtx.  Thus, if the
                    678:      compiler knows that both source and destination are word-aligned,
                    679:      it may provide the value 4 for this operand.
                    680: 
                    681:      These patterns need not give special consideration to the
                    682:      possibility that the source and destination strings might overlap.
                    683: 
                    684: `cmpstrM'
                    685:      Block compare instruction, with five operands.  Operand 0 is the
                    686:      output; it has mode M.  The remaining four operands are like the
                    687:      operands of `movstrM'.  The two memory blocks specified are
                    688:      compared byte by byte in lexicographic order.  The effect of the
                    689:      instruction is to store a value in operand 0 whose sign indicates
                    690:      the result of the comparison.
                    691: 
                    692: `floatMN2'
                    693:      Convert signed integer operand 1 (valid for fixed point mode M) to
                    694:      floating point mode N and store in operand 0 (which has mode N).
                    695: 
                    696: `floatunsMN2'
                    697:      Convert unsigned integer operand 1 (valid for fixed point mode M)
                    698:      to floating point mode N and store in operand 0 (which has mode
                    699:      N).
                    700: 
                    701: `fixMN2'
                    702:      Convert operand 1 (valid for floating point mode M) to fixed
                    703:      point mode N as a signed number and store in operand 0 (which has
                    704:      mode N).  This instruction's result is defined only when the
                    705:      value of operand 1 is an integer.
                    706: 
                    707: `fixunsMN2'
                    708:      Convert operand 1 (valid for floating point mode M) to fixed
                    709:      point mode N as an unsigned number and store in operand 0 (which
                    710:      has mode N).  This instruction's result is defined only when the
                    711:      value of operand 1 is an integer.
                    712: 
                    713: `ftruncM2'
                    714:      Convert operand 1 (valid for floating point mode M) to an integer
                    715:      value, still represented in floating point mode M, and store it
                    716:      in operand 0 (valid for floating point mode M).
                    717: 
                    718: `fix_truncMN2'
                    719:      Like `fixMN2' but works for any floating point value of mode M by
                    720:      converting the value to an integer.
                    721: 
                    722: `fixuns_truncMN2'
                    723:      Like `fixunsMN2' but works for any floating point value of mode M
                    724:      by converting the value to an integer.
                    725: 
                    726: `truncMN'
                    727:      Truncate operand 1 (valid for mode M) to mode N and store in
                    728:      operand 0 (which has mode N).  Both modes must be fixed point or
                    729:      both floating point.
                    730: 
                    731: `extendMN'
                    732:      Sign-extend operand 1 (valid for mode M) to mode N and store in
                    733:      operand 0 (which has mode N).  Both modes must be fixed point or
                    734:      both floating point.
                    735: 
                    736: `zero_extendMN'
                    737:      Zero-extend operand 1 (valid for mode M) to mode N and store in
                    738:      operand 0 (which has mode N).  Both modes must be fixed point.
                    739: 
                    740: `extv'
                    741:      Extract a bit field from operand 1 (a register or memory
                    742:      operand), where operand 2 specifies the width in bits and operand
                    743:      3 the starting bit, and store it in operand 0.  Operand 0 must
                    744:      have mode `word_mode'.  Operand 1 may have mode `byte_mode' or
                    745:      `word_mode'; often `word_mode' is allowed only for registers. 
                    746:      Operands 2 and 3 must be valid for `word_mode'.
                    747: 
                    748:      The RTL generation pass generates this instruction only with
                    749:      constants for operands 2 and 3.
                    750: 
                    751:      The bit-field value is sign-extended to a full word integer
                    752:      before it is stored in operand 0.
                    753: 
                    754: `extzv'
                    755:      Like `extv' except that the bit-field value is zero-extended.
                    756: 
                    757: `insv'
                    758:      Store operand 3 (which must be valid for `word_mode') into a bit
                    759:      field in operand 0, where operand 1 specifies the width in bits
                    760:      and operand 2 the starting bit.  Operand 0 may have mode
                    761:      `byte_mode' or `word_mode'; often `word_mode' is allowed only for
                    762:      registers.  Operands 1 and 2 must be valid for `word_mode'.
                    763: 
                    764:      The RTL generation pass generates this instruction only with
                    765:      constants for operands 1 and 2.
                    766: 
                    767: `sCOND'
                    768:      Store zero or nonzero in the operand according to the condition
                    769:      codes.  Value stored is nonzero iff the condition COND is true. 
                    770:      COND is the name of a comparison operation expression code, such
                    771:      as `eq', `lt' or `leu'.
                    772: 
                    773:      You specify the mode that the operand must have when you write the
                    774:      `match_operand' expression.  The compiler automatically sees
                    775:      which mode you have used and supplies an operand of that mode.
                    776: 
                    777:      The value stored for a true condition must have 1 as its low bit,
                    778:      or else must be negative.  Otherwise the instruction is not
                    779:      suitable and you should omit it from the machine description. 
                    780:      You describe to the compiler exactly which value is stored by
                    781:      defining the macro `STORE_FLAG_VALUE' (*note Misc::.).  If a
                    782:      description cannot be found that can be used for all the `sCOND'
                    783:      patterns, you should omit those operations from the machine
                    784:      description.
                    785: 
                    786:      These operations may fail, but should do so only in relatively
                    787:      uncommon cases; if they would fail for common cases involving
                    788:      integer comparisons, it is best to omit these patterns.
                    789: 
                    790:      If these operations are omitted, the compiler will usually
                    791:      generate code that copies the constant one to the target and
                    792:      branches around an assignment of zero to the target.  If this
                    793:      code is more efficient than the potential instructions used for
                    794:      the `sCOND' pattern followed by those required to convert the
                    795:      result into a 1 or a zero in `SImode', you should omit the
                    796:      `sCOND' operations from the machine description.
                    797: 
                    798: `bCOND'
                    799:      Conditional branch instruction.  Operand 0 is a `label_ref' that
                    800:      refers to the label to jump to.  Jump if the condition codes meet
                    801:      condition COND.
                    802: 
                    803:      Some machines do not follow the model assumed here where a
                    804:      comparison instruction is followed by a conditional branch
                    805:      instruction.  In that case, the `cmpM' (and `tstM') patterns
                    806:      should simply store the operands away and generate all the
                    807:      required insns in a `define_expand' (*note Expander
                    808:      Definitions::.) for the conditional branch operations.  All calls
                    809:      to expand `vCOND' patterns are immediately preceded by calls to
                    810:      expand either a `cmpM' pattern or a `tstM' pattern.
                    811: 
                    812:      Machines that use a pseudo register for the condition code value,
                    813:      or where the mode used for the comparison depends on the
                    814:      condition being tested, should also use the above mechanism. 
                    815:      *Note Jump Patterns::
                    816: 
                    817:      The above discussion also applies to `sCOND' patterns.
                    818: 
                    819: `call'
                    820:      Subroutine call instruction returning no value.  Operand 0 is the
                    821:      function to call; operand 1 is the number of bytes of arguments
                    822:      pushed (in mode `SImode', except it is normally a `const_int');
                    823:      operand 2 is the number of registers used as operands.
                    824: 
                    825:      On most machines, operand 2 is not actually stored into the RTL
                    826:      pattern.  It is supplied for the sake of some RISC machines which
                    827:      need to put this information into the assembler code; they can
                    828:      put it in the RTL instead of operand 1.
                    829: 
                    830:      Operand 0 should be a `mem' RTX whose address is the address of
                    831:      the function.  Note, however, that this address can be a
                    832:      `symbol_ref' expression even if it would not be a legitimate
                    833:      memory address on the target machine.  If it is also not a valid
                    834:      argument for a call instruction, the pattern for this operation
                    835:      should be a `define_expand' (*note Expander Definitions::.) that
                    836:      places the address into a register and uses that register in the
                    837:      call instruction.
                    838: 
                    839: `call_value'
                    840:      Subroutine call instruction returning a value.  Operand 0 is the
                    841:      hard register in which the value is returned.  There are three
                    842:      more operands, the same as the three operands of the `call'
                    843:      instruction (but with numbers increased by one).
                    844: 
                    845:      Subroutines that return `BLKmode' objects use the `call' insn.
                    846: 
                    847: `call_pop', `call_value_pop'
                    848:      Similar to `call' and `call_value', except used if defined and if
                    849:      `RETURN_POPS_ARGS' is non-zero.  They should emit a `parallel'
                    850:      that contains both the function call and a `set' to indicate the
                    851:      adjustment made to the frame pointer.
                    852: 
                    853:      For machines where `RETURN_POPS_ARGS' can be non-zero, the use of
                    854:      these patterns increases the number of functions for which the
                    855:      frame pointer can be eliminated, if desired.
                    856: 
                    857: `return'
                    858:      Subroutine return instruction.  This instruction pattern name
                    859:      should be defined only if a single instruction can do all the
                    860:      work of returning from a function.
                    861: 
                    862:      Like the `movM' patterns, this pattern is also used after the RTL
                    863:      generation phase.  In this case it is to support machines where
                    864:      multiple instructions are usually needed to return from a
                    865:      function, but some class of functions only requires one
                    866:      instruction to implement a return.  Normally, the applicable
                    867:      functions are those which do not need to save any registers or
                    868:      allocate stack space.
                    869: 
                    870:      For such machines, the condition specified in this pattern should
                    871:      only be true when `reload_completed' is non-zero and the
                    872:      function's epilogue would only be a single instruction.  For
                    873:      machines with register windows, the routine `leaf_function_p' may
                    874:      be used to determine if a register window push is required.
                    875: 
                    876:      Machines that have conditional return instructions should define
                    877:      patterns such as
                    878: 
                    879:           (define_insn ""
                    880:             [(set (pc)
                    881:                (if_then_else (match_operator 0 "comparison_operator"
                    882:                                              [(cc0) (const_int 0)])
                    883:                              (return)
                    884:                              (pc)))]
                    885:             "CONDITION"
                    886:             "...")
                    887: 
                    888:      where CONDITION would normally be the same condition specified on
                    889:      the named `return' pattern.
                    890: 
                    891: `nop'
                    892:      No-op instruction.  This instruction pattern name should always
                    893:      be defined to output a no-op in assembler code.  `(const_int 0)'
                    894:      will do as an RTL pattern.
                    895: 
                    896: `indirect_jump'
                    897:      An instruction to jump to an address which is operand zero.  This
                    898:      pattern name is mandatory on all machines.
                    899: 
                    900: `casesi'
                    901:      Instruction to jump through a dispatch table, including bounds
                    902:      checking.  This instruction takes five operands:
                    903: 
                    904:        1. The index to dispatch on, which has mode `SImode'.
                    905: 
                    906:        2. The lower bound for indices in the table, an integer
                    907:           constant.
                    908: 
                    909:        3. The total range of indices in the table--the largest index
                    910:           minus the smallest one (both inclusive).
                    911: 
                    912:        4. A label that precedes the table itself.
                    913: 
                    914:        5. A label to jump to if the index has a value outside the
                    915:           bounds.  (If the machine-description macro
                    916:           `CASE_DROPS_THROUGH' is defined, then an out-of-bounds index
                    917:           drops through to the code following the jump table instead
                    918:           of jumping to this label.  In that case, this label is not
                    919:           actually used by the `casesi' instruction, but it is always
                    920:           provided as an operand.)
                    921: 
                    922:      The table is a `addr_vec' or `addr_diff_vec' inside of a
                    923:      `jump_insn'.  The number of elements in the table is one plus the
                    924:      difference between the upper bound and the lower bound.
                    925: 
                    926: `tablejump'
                    927:      Instruction to jump to a variable address.  This is a low-level
                    928:      capability which can be used to implement a dispatch table when
                    929:      there is no `casesi' pattern.
                    930: 
                    931:      This pattern requires two operands: the address or offset, and a
                    932:      label which should immediately precede the jump table.  If the
                    933:      macro `CASE_VECTOR_PC_RELATIVE' is defined then the first operand
                    934:      is an offset which counts from the address of the table;
                    935:      otherwise, it is an absolute address to jump to.
                    936: 
                    937:      The `tablejump' insn is always the last insn before the jump
                    938:      table it uses.  Its assembler code normally has no need to use the
                    939:      second operand, but you should incorporate it in the RTL pattern
                    940:      so that the jump optimizer will not delete the table as
                    941:      unreachable code.
                    942: 
                    943: 
                    944: File: gcc.info,  Node: Pattern Ordering,  Next: Dependent Patterns,  Prev: Standard Names,  Up: Machine Desc
                    945: 
                    946: When the Order of Patterns Matters
                    947: ==================================
                    948: 
                    949:    Sometimes an insn can match more than one instruction pattern. 
                    950: Then the pattern that appears first in the machine description is the
                    951: one used.  Therefore, more specific patterns (patterns that will match
                    952: fewer things) and faster instructions (those that will produce better
                    953: code when they do match) should usually go first in the description.
                    954: 
                    955:    In some cases the effect of ordering the patterns can be used to
                    956: hide a pattern when it is not valid.  For example, the 68000 has an
                    957: instruction for converting a fullword to floating point and another
                    958: for converting a byte to floating point.  An instruction converting an
                    959: integer to floating point could match either one.  We put the pattern
                    960: to convert the fullword first to make sure that one will be used
                    961: rather than the other.  (Otherwise a large integer might be generated
                    962: as a single-byte immediate quantity, which would not work.) Instead of
                    963: using this pattern ordering it would be possible to make the pattern
                    964: for convert-a-byte smart enough to deal properly with any constant
                    965: value.
                    966: 
                    967: 
                    968: File: gcc.info,  Node: Dependent Patterns,  Next: Jump Patterns,  Prev: Pattern Ordering,  Up: Machine Desc
                    969: 
                    970: Interdependence of Patterns
                    971: ===========================
                    972: 
                    973:    Every machine description must have a named pattern for each of the
                    974: conditional branch names `bCOND'.  The recognition template must
                    975: always have the form
                    976: 
                    977:      (set (pc)
                    978:           (if_then_else (COND (cc0) (const_int 0))
                    979:                         (label_ref (match_operand 0 "" ""))
                    980:                         (pc)))
                    981: 
                    982: In addition, every machine description must have an anonymous pattern
                    983: for each of the possible reverse-conditional branches.  Their templates
                    984: look like
                    985: 
                    986:      (set (pc)
                    987:           (if_then_else (COND (cc0) (const_int 0))
                    988:                         (pc)
                    989:                         (label_ref (match_operand 0 "" ""))))
                    990: 
                    991: They are necessary because jump optimization can turn
                    992: direct-conditional branches into reverse-conditional branches.
                    993: 
                    994:    It is often convenient to use the `match_operator' construct to
                    995: reduce the number of patterns that must be specified for branches.  For
                    996: example,
                    997: 
                    998:      (define_insn ""
                    999:        [(set (pc)
                   1000:              (if_then_else (match_operator 0 "comparison_operator"
                   1001:                                      [(cc0) (const_int 0)])
                   1002:                      (pc)
                   1003:                      (label_ref (match_operand 1 "" ""))))]
                   1004:        "CONDITION"
                   1005:        "...")
                   1006: 
                   1007:    In some cases machines support instructions identical except for the
                   1008: machine mode of one or more operands.  For example, there may be
                   1009: "sign-extend halfword" and "sign-extend byte" instructions whose
                   1010: patterns are
                   1011: 
                   1012:      (set (match_operand:SI 0 ...)
                   1013:           (extend:SI (match_operand:HI 1 ...)))
                   1014:      
                   1015:      (set (match_operand:SI 0 ...)
                   1016:           (extend:SI (match_operand:QI 1 ...)))
                   1017: 
                   1018: Constant integers do not specify a machine mode, so an instruction to
                   1019: extend a constant value could match either pattern.  The pattern it
                   1020: actually will match is the one that appears first in the file.  For
                   1021: correct results, this must be the one for the widest possible mode
                   1022: (`HImode', here).  If the pattern matches the `QImode' instruction,
                   1023: the results will be incorrect if the constant value does not actually
                   1024: fit that mode.
                   1025: 
                   1026:    Such instructions to extend constants are rarely generated because
                   1027: they are optimized away, but they do occasionally happen in
                   1028: nonoptimized compilations.
                   1029: 
                   1030:    If a constraint in a pattern allows a constant, the reload pass may
                   1031: replace a register with a constant permitted by the constraint in some
                   1032: cases.  Similarly for memory references.  You must ensure that the
                   1033: predicate permits all objects allowed by the constraints to prevent the
                   1034: compiler from crashing.
                   1035: 
                   1036:    Because of this substitution, you should not provide separate
                   1037: patterns for increment and decrement instructions.  Instead, they
                   1038: should be generated from the same pattern that supports
                   1039: register-register add insns by examining the operands and generating
                   1040: the appropriate machine instruction.
                   1041: 
                   1042: 
                   1043: File: gcc.info,  Node: Jump Patterns,  Next: Insn Canonicalizations,  Prev: Dependent Patterns,  Up: Machine Desc
                   1044: 
                   1045: Defining Jump Instruction Patterns
                   1046: ==================================
                   1047: 
                   1048:    For most machines, GNU CC assumes that the machine has a condition
                   1049: code.  A comparison insn sets the condition code, recording the
                   1050: results of both signed and unsigned comparison of the given operands. 
                   1051: A separate branch insn tests the condition code and branches or not
                   1052: according its value.  The branch insns come in distinct signed and
                   1053: unsigned flavors.  Many common machines, such as the Vax, the 68000
                   1054: and the 32000, work this way.
                   1055: 
                   1056:    Some machines have distinct signed and unsigned compare
                   1057: instructions, and only one set of conditional branch instructions. 
                   1058: The easiest way to handle these machines is to treat them just like
                   1059: the others until the final stage where assembly code is written.  At
                   1060: this time, when outputting code for the compare instruction, peek
                   1061: ahead at the following branch using `next_cc0_user (insn)'.  (The
                   1062: variable `insn' refers to the insn being output, in the output-writing
                   1063: code in an instruction pattern.)  If the RTL says that is an unsigned
                   1064: branch, output an unsigned compare; otherwise output a signed compare.
                   1065:  When the branch itself is output, you can treat signed and unsigned
                   1066: branches identically.
                   1067: 
                   1068:    The reason you can do this is that GNU CC always generates a pair of
                   1069: consecutive RTL insns, possibly separated by `note' insns, one to set
                   1070: the condition code and one to test it, and keeps the pair inviolate
                   1071: until the end.
                   1072: 
                   1073:    To go with this technique, you must define the machine-description
                   1074: macro `NOTICE_UPDATE_CC' to do `CC_STATUS_INIT'; in other words, no
                   1075: compare instruction is superfluous.
                   1076: 
                   1077:    Some machines have compare-and-branch instructions and no condition
                   1078: code.  A similar technique works for them.  When it is time to
                   1079: "output" a compare instruction, record its operands in two static
                   1080: variables.  When outputting the branch-on-condition-code instruction
                   1081: that follows, actually output a compare-and-branch instruction that
                   1082: uses the remembered operands.
                   1083: 
                   1084:    It also works to define patterns for compare-and-branch
                   1085: instructions.  In optimizing compilation, the pair of compare and
                   1086: branch instructions will be combined according to these patterns.  But
                   1087: this does not happen if optimization is not requested.  So you must
                   1088: use one of the solutions above in addition to any special patterns you
                   1089: define.
                   1090: 
                   1091:    In many RISC machines, most instructions do not affect the condition
                   1092: code and there may not even be a separate condition code register.  On
                   1093: these machines, the restriction that the definition and use of the
                   1094: condition code be adjacent insns is not necessary and can prevent
                   1095: important optimizations.  For example, on the IBM RS/6000, there is a
                   1096: delay for taken branches unless the condition code register is set
                   1097: three instructions earlier than the conditional branch.  The
                   1098: instruction scheduler cannot perform this optimization if it is not
                   1099: permitted to separate the definition and use of the condition code
                   1100: register.
                   1101: 
                   1102:    On these machines, do not use `(cc0)', but instead use a register
                   1103: to represent the condition code.  If there is a specific condition code
                   1104: register in the machine, use a hard register.  If the condition code or
                   1105: comparison result can be placed in any general register, or if there
                   1106: are multiple condition registers, use a pseudo register.
                   1107: 
                   1108:    On some machines, the type of branch instruction generated may
                   1109: depend on the way the condition code was produced; for example, on the
                   1110: 68k and Sparc, setting the condition code directly from an add or
                   1111: subtract instruction does not clear the overflow bit the way that a
                   1112: test instruction does, so a different branch instruction must be used
                   1113: for some conditional branches.  For machines that use `(cc0)', the set
                   1114: and use of the condition code must be adjacent (separated only by
                   1115: `note' insns) allowing flags in `cc_status' to be used.  (*Note
                   1116: Condition Code::.)  Also, the comparison and branch insns can be
                   1117: located from each other by using the functions `prev_cc0_setter' and
                   1118: `next_cc0_user'.
                   1119: 
                   1120:    However, this is not true on machines that do not use `(cc0)'.  On
                   1121: those machines, no assumptions can be made about the adjacency of the
                   1122: compare and branch insns and the above methods cannot be used. 
                   1123: Instead, we use the machine mode of the condition code register to
                   1124: record different formats of the condition code register.
                   1125: 
                   1126:    Registers used to store the condition code value should have a mode
                   1127: that is in class `MODE_CC'.  Normally, it will be `CCmode'.  If
                   1128: additional modes are required (as for the add example mentioned above
                   1129: in the Sparc), define the macro `EXTRA_CC_MODES' to list the
                   1130: additional modes required (*note Condition Code::.).  Also define
                   1131: `EXTRA_CC_NAMES' to list the names of those modes and `SELECT_CC_MODE'
                   1132: to choose a mode given an operand of a compare.
                   1133: 
                   1134:    If it is known during RTL generation that a different mode will be
                   1135: required (for example, if the machine has separate compare instructions
                   1136: for signed and unsigned quantities, like most IBM processors), they can
                   1137: be specified at that time.
                   1138: 
                   1139:    If the cases that require different modes would be made by
                   1140: instruction combination, the macro `SELECT_CC_MODE' determines which
                   1141: machine mode should be used for the comparison result.  The patterns
                   1142: should be written using that mode.  To support the case of the add on
                   1143: the Sparc discussed above, we have the pattern
                   1144: 
                   1145:      (define_insn ""
                   1146:        [(set (reg:CC_NOOV 0)
                   1147:        (compare:CC_NOOV (plus:SI (match_operand:SI 0 "register_operand" "%r")
                   1148:                                  (match_operand:SI 1 "arith_operand" "rI"))
                   1149:                         (const_int 0)))]
                   1150:        ""
                   1151:        "...")
                   1152: 
                   1153:    The `SELECT_CC_MODE' macro on the Sparc returns `CC_NOOVmode' for
                   1154: comparisons whose argument is a `plus'.
                   1155: 
                   1156: 

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