Often a single fixed template string cannot produce correct and efficient assembler code for all the cases that are recognized by a single instruction pattern. For example, the opcodes may depend on the kinds of operands; or some unfortunate combinations of operands may require extra machine instructions.
If the output control string starts with a `@', then it is actually a series of templates, each on a separate line. (Blank lines and leading spaces and tabs are ignored.) The templates correspond to the pattern's constraint alternatives (see section Multiple Alternative Constraints). For example, if a target machine has a two-address add instruction `addr' to add into a register and another `addm' to add a register to memory, you might write this pattern:
(define_insn "addsi3" [(set (match_operand:SI 0 "general_operand" "=r,m") (plus:SI (match_operand:SI 1 "general_operand" "0,0") (match_operand:SI 2 "general_operand" "g,r")))] "" "@ addr %2,%0 addm %2,%0")
If the output control string starts with a `*', then it is not an
output template but rather a piece of C program that should compute a
template. It should execute a
return statement to return the
template-string you want. Most such templates use C string literals, which
require doublequote characters to delimit them. To include these
doublequote characters in the string, prefix each one with `\'.
The operands may be found in the array
operands, whose C data type
It is very common to select different ways of generating assembler code
based on whether an immediate operand is within a certain range. Be
careful when doing this, because the result of
INTVAL is an
integer on the host machine. If the host machine has more bits in an
int than the target machine has in the mode in which the constant
will be used, then some of the bits you get from
INTVAL will be
superfluous. For proper results, you must carefully disregard the
values of those bits.
It is possible to output an assembler instruction and then go on to output
or compute more of them, using the subroutine
receives two arguments: a template-string and a vector of operands. The
vector may be
operands, or it may be another array of
that you declare locally and initialize yourself.
When an insn pattern has multiple alternatives in its constraints, often
the appearance of the assembler code is determined mostly by which alternative
was matched. When this is so, the C code can test the variable
which_alternative, which is the ordinal number of the alternative
that was actually satisfied (0 for the first, 1 for the second alternative,
For example, suppose there are two opcodes for storing zero, `clrreg'
for registers and `clrmem' for memory locations. Here is how
a pattern could use
which_alternative to choose between them:
(define_insn "" [(set (match_operand:SI 0 "general_operand" "=r,m") (const_int 0))] "" "* return (which_alternative == 0 ? \"clrreg %0\" : \"clrmem %0\"); ")
The example above, where the assembler code to generate was solely determined by the alternative, could also have been specified as follows, having the output control string start with a `@':
(define_insn "" [(set (match_operand:SI 0 "general_operand" "=r,m") (const_int 0))] "" "@ clrreg %0 clrmem %0")