home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Fresh Fish 7
/
FreshFishVol7.bin
/
bbs
/
gnu
/
gcc-2.5.8-bin.lha
/
GNU
/
info
/
gcc.info-16
(
.txt
)
< prev
next >
Wrap
GNU Info File
|
1994-09-02
|
49KB
|
873 lines
This is Info file gcc.info, produced by Makeinfo-1.54 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