If an .md file construct uses mode iterators, each version of the construct will often need slightly different strings or modes. For example:
define_expand
defines several add
m3
patterns
(see Standard Names), each expander will need to use the
appropriate mode name for m.
define_insn
defines several instruction patterns,
each instruction will often use a different assembler mnemonic.
define_insn
requires operands with different modes,
using an iterator for one of the operand modes usually requires a specific
mode for the other operand(s).
GCC supports such variations through a system of “mode attributes”.
There are two standard attributes: mode
, which is the name of
the mode in lower case, and MODE
, which is the same thing in
upper case. You can define other attributes using:
(define_mode_attr name [(mode1 "value1") ... (moden "valuen")])
where name is the name of the attribute and valuei is the value associated with modei.
When GCC replaces some :iterator with :mode, it will scan
each string and mode in the pattern for sequences of the form
<
iterator:
attr>
, where attr is the name of a
mode attribute. If the attribute is defined for mode, the whole
<...>
sequence will be replaced by the appropriate attribute
value.
For example, suppose an .md file has:
(define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) (define_mode_attr load [(SI "lw") (DI "ld")])
If one of the patterns that uses :P
contains the string
"<P:load>\t%0,%1"
, the SI
version of that pattern
will use "lw\t%0,%1"
and the DI
version will use
"ld\t%0,%1"
.
Here is an example of using an attribute for a mode:
(define_mode_iterator LONG [SI DI]) (define_mode_attr SHORT [(SI "HI") (DI "SI")]) (define_insn ... (sign_extend:LONG (match_operand:<LONG:SHORT> ...)) ...)
The iterator:
prefix may be omitted, in which case the
substitution will be attempted for every iterator expansion.