Fresh Fish 4/FreshFish_May-June1994.bin/gnu/info/gcc.info-15

GNU Info File | 1994-02-20 | 49KB | 877 lines

This is Info file gcc.info, produced by Makeinfo-1.55 from the input
file gcc.texi.
   This file documents the use and the internals of the GNU compiler.
   Published by the Free Software Foundation 675 Massachusetts Avenue
Cambridge, MA 02139 USA
   Copyright (C) 1988, 1989, 1992, 1993 Free Software Foundation, Inc.
   Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.
   Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the sections entitled "GNU General Public License" and "Protect
Your Freedom--Fight `Look And Feel'" are included exactly as in the
original, and provided that the entire resulting derived work is
distributed under the terms of a permission notice identical to this
   Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the sections entitled "GNU General Public
License" and "Protect Your Freedom--Fight `Look And Feel'", and this
permission notice, may be included in translations approved by the Free
Software Foundation instead of in the original English.
File: gcc.info,  Node: Standard Names,  Next: Pattern Ordering,  Prev: Constraints,  Up: Machine Desc
Standard Pattern Names For Generation
=====================================
   Here is a table of the instruction names that are meaningful in the
RTL generation pass of the compiler.  Giving one of these names to an
instruction pattern tells the RTL generation pass that it can use the
pattern in to accomplish a certain task.
`movM'
     Here M stands for a two-letter machine mode name, in lower case.
     This instruction pattern moves data with that machine mode from
     operand 1 to operand 0.  For example, `movsi' moves full-word data.
     If operand 0 is a `subreg' with mode M of a register whose own
     mode is wider than M, the effect of this instruction is to store
     the specified value in the part of the register that corresponds
     to mode M.  The effect on the rest of the register is undefined.
     This class of patterns is special in several ways.  First of all,
     each of these names *must* be defined, because there is no other
     way to copy a datum from one place to another.
     Second, these patterns are not used solely in the RTL generation
     pass.  Even the reload pass can generate move insns to copy values
     from stack slots into temporary registers.  When it does so, one
     of the operands is a hard register and the other is an operand
     that can need to be reloaded into a register.
     Therefore, when given such a pair of operands, the pattern must
     generate RTL which needs no reloading and needs no temporary
     registers--no registers other than the operands.  For example, if
     you support the pattern with a `define_expand', then in such a
     case the `define_expand' mustn't call `force_reg' or any other such
     function which might generate new pseudo registers.
     This requirement exists even for subword modes on a RISC machine
     where fetching those modes from memory normally requires several
     insns and some temporary registers.  Look in `spur.md' to see how
     the requirement can be satisfied.
     During reload a memory reference with an invalid address may be
     passed as an operand.  Such an address will be replaced with a
     valid address later in the reload pass.  In this case, nothing may
     be done with the address except to use it as it stands.  If it is
     copied, it will not be replaced with a valid address.  No attempt
     should be made to make such an address into a valid address and no
     routine (such as `change_address') that will do so may be called.
     Note that `general_operand' will fail when applied to such an
     address.
     The global variable `reload_in_progress' (which must be explicitly
     declared if required) can be used to determine whether such special
     handling is required.
     The variety of operands that have reloads depends on the rest of
     the machine description, but typically on a RISC machine these can
     only be pseudo registers that did not get hard registers, while on
     other machines explicit memory references will get optional
     reloads.
     If a scratch register is required to move an object to or from
     memory, it can be allocated using `gen_reg_rtx' prior to reload.
     But this is impossible during and after reload.  If there are
     cases needing scratch registers after reload, you must define
     `SECONDARY_INPUT_RELOAD_CLASS' and perhaps also
     `SECONDARY_OUTPUT_RELOAD_CLASS' to detect them, and provide
     patterns `reload_inM' or `reload_outM' to handle them.  *Note
     Register Classes::.
     The constraints on a `moveM' must permit moving any hard register
     to any other hard register provided that `HARD_REGNO_MODE_OK'
     permits mode M in both registers and `REGISTER_MOVE_COST' applied
     to their classes returns a value of 2.
     It is obligatory to support floating point `moveM' instructions
     into and out of any registers that can hold fixed point values,
     because unions and structures (which have modes `SImode' or
     `DImode') can be in those registers and they may have floating
     point members.
     There may also be a need to support fixed point `moveM'
     instructions in and out of floating point registers.
     Unfortunately, I have forgotten why this was so, and I don't know
     whether it is still true.  If `HARD_REGNO_MODE_OK' rejects fixed
     point values in floating point registers, then the constraints of
     the fixed point `moveM' instructions must be designed to avoid
     ever trying to reload into a floating point register.
`reload_inM'
`reload_outM'
     Like `movM', but used when a scratch register is required to move
     between operand 0 and operand 1.  Operand 2 describes the scratch
     register.  See the discussion of the `SECONDARY_RELOAD_CLASS'
     macro in *note Register Classes::..
`movstrictM'
     Like `movM' except that if operand 0 is a `subreg' with mode M of
     a register whose natural mode is wider, the `movstrictM'
     instruction is guaranteed not to alter any of the register except
     the part which belongs to mode M.
`load_multiple'
     Load several consecutive memory locations into consecutive
     registers.  Operand 0 is the first of the consecutive registers,
     operand 1 is the first memory location, and operand 2 is a
     constant: the number of consecutive registers.
     Define this only if the target machine really has such an
     instruction; do not define this if the most efficient way of
     loading consecutive registers from memory is to do them one at a
     time.
     On some machines, there are restrictions as to which consecutive
     registers can be stored into memory, such as particular starting or
     ending register numbers or only a range of valid counts.  For those
     machines, use a `define_expand' (*note Expander Definitions::.)
     and make the pattern fail if the restrictions are not met.
     Write the generated insn as a `parallel' with elements being a
     `set' of one register from the appropriate memory location (you may
     also need `use' or `clobber' elements).  Use a `match_parallel'
     (*note RTL Template::.) to recognize the insn.  See `a29k.md' and
     `rs6000.md' for examples of the use of this insn pattern.
`store_multiple'
     Similar to `load_multiple', but store several consecutive registers
     into consecutive memory locations.  Operand 0 is the first of the
     consecutive memory locations, operand 1 is the first register, and
     operand 2 is a constant: the number of consecutive registers.
`addM3'
     Add operand 2 and operand 1, storing the result in operand 0.  All
     operands must have mode M.  This can be used even on two-address
     machines, by means of constraints requiring operands 1 and 0 to be
     the same location.
`subM3', `mulM3'
`divM