The simplest kind of constraint is a string full of letters, each of which describes one kind of operand that is permitted. Here are the letters that are allowed:
For example, an address which is constant is offsettable; so is an address that is the sum of a register and a constant (as long as a slightly larger constant is also within the range of address-offsets supported by the machine); but an autoincrement or autodecrement address is not offsettable. More complicated indirect/indexed addresses may or may not be offsettable depending on the other addressing modes that the machine supports.
Note that in an output operand which can be matched by another
operand, the constraint letter
o is valid only when accompanied
< (if the target machine has predecrement addressing)
> (if the target machine has preincrement addressing).
mconstraint but not the
Pmay be defined in a machine-dependent fashion to permit immediate integer operands with explicit integer values in specified ranges. For example, on the 68000,
Iis defined to stand for the range of values 1 to 8. This is the range permitted as a shift count in the shift instructions.
const_double) is allowed, but only if the target floating point format is the same as that of the host machine (on which the compiler is running).
const_double) is allowed.
Hmay be defined in a machine-dependent fashion to permit immediate floating operands in particular ranges of values.
This might appear strange; if an insn allows a constant operand with a
value not known at compile time, it certainly must allow any known
value. So why use
s instead of
i? Sometimes it allows
better code to be generated.
For example, on the 68000 in a fullword instruction it is possible to
use an immediate operand; but if the immediate value is between -128
and 127, better code results from loading the value into a register and
using the register. This is because the load into the register can be
done with a
moveq instruction. We arrange for this to happen
by defining the letter
K to mean "any integer outside the
range -128 to 127", and then specifying
Ks in the operand
general_operand. This is normally used in the constraint of a
match_scratchwhen certain alternatives will not actually require a scratch register.
This number is allowed to be more than a single digit. If multiple
digits are encountered consecutavely, they are interpreted as a single
decimal integer. There is scant chance for ambiguity, since to-date
it has never been desirable that
10 be interpreted as matching
either operand 1 or operand 0. Should this be desired, one
can use multiple alternatives instead.
This is called a matching constraint and what it really means is that the assembler has only a single operand that fills two roles considered separate in the RTL insn. For example, an add insn has two input operands and one output operand in the RTL, but on most CISC machines an add instruction really has only two operands, one of them an input-output operand:
Matching constraints are used in these circumstances. More precisely, the two operands that match must include one input-only operand and one output-only operand. Moreover, the digit must be a smaller number than the number of the operand that uses it in the constraint.
For operands to match in a particular case usually means that they
are identical-looking RTL expressions. But in a few special cases
specific kinds of dissimilarity are allowed. For example,
as an input operand will match
*x++ as an output operand.
For proper results in such cases, the output template should always
use the output-operand's number when printing the operand.
p in the constraint must be accompanied by
as the predicate in the
match_operand. This predicate interprets
the mode specified in the
match_operand as the mode of the memory
reference for which the address would be valid.
fare defined on the 68000/68020 to stand for data, address and floating point registers.
The machine description macro
REG_CLASS_FROM_LETTER has first
cut at the otherwise unused letters. If it evaluates to
EXTRA_CONSTRAINT is evaluated.
A typical use for
EXTRA_CONSTRANT would be to distinguish certain
types of memory references that affect other insn operands.
In order to have valid assembler code, each operand must satisfy its constraint. But a failure to do so does not prevent the pattern from applying to an insn. Instead, it directs the compiler to modify the code so that the constraint will be satisfied. Usually this is done by copying an operand into a register.
Contrast, therefore, the two instruction patterns that follow:
(define_insn "" [(set (match_operand:SI 0 "general_operand" "=r") (plus:SI (match_dup 0) (match_operand:SI 1 "general_operand" "r")))] "" "...")
which has two operands, one of which must appear in two places, and
(define_insn "" [(set (match_operand:SI 0 "general_operand" "=r") (plus:SI (match_operand:SI 1 "general_operand" "0") (match_operand:SI 2 "general_operand" "r")))] "" "...")
which has three operands, two of which are required by a constraint to be identical. If we are considering an insn of the form
(insn n prev next (set (reg:SI 3) (plus:SI (reg:SI 6) (reg:SI 109))) ...)
the first pattern would not apply at all, because this insn does not contain two identical subexpressions in the right place. The pattern would say, "That does not look like an add instruction; try other patterns." The second pattern would say, "Yes, that's an add instruction, but there is something wrong with it." It would direct the reload pass of the compiler to generate additional insns to make the constraint true. The results might look like this:
(insn n2 prev n (set (reg:SI 3) (reg:SI 6)) ...) (insn n n2 next (set (reg:SI 3) (plus:SI (reg:SI 3) (reg:SI 109))) ...)
It is up to you to make sure that each operand, in each pattern, has constraints that can handle any RTL expression that could be present for that operand. (When multiple alternatives are in use, each pattern must, for each possible combination of operand expressions, have at least one alternative which can handle that combination of operands.) The constraints don't need to allow any possible operand--when this is the case, they do not constrain--but they must at least point the way to reloading any possible operand so that it will fit.
For example, an operand whose constraints permit everything except registers is safe provided its predicate rejects registers.
An operand whose predicate accepts only constant values is safe
provided its constraints include the letter
i. If any possible
constant value is accepted, then nothing less than
i will do;
if the predicate is more selective, then the constraints may also be
o, all memory references are taken care of.
m, constant operands are not a problem.
If the operand's predicate can recognize registers, but the constraint does not permit them, it can make the compiler crash. When this operand happens to be a register, the reload pass will be stymied, because it does not know how to copy a register temporarily into memory.
If the predicate accepts a unary operator, the constraint applies to the
operand. For example, the MIPS processor at ISA level 3 supports an
instruction which adds two registers in
SImode to produce a
DImode result, but only if the registers are correctly sign
extended. This predicate for the input operands accepts a
sign_extend of an
SImode register. Write the constraint
to indicate the type of register that is required for the operand of the