Bernhard Rosenkraenzer | c83ebe5 | 2012-09-18 21:38:03 +0159 | [diff] [blame] | 1 | @c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1996, 1998, 1999, 2000, 2001, |
| 2 | @c 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011 |
| 3 | @c Free Software Foundation, Inc. |
| 4 | @c This is part of the GCC manual. |
| 5 | @c For copying conditions, see the file gcc.texi. |
| 6 | |
| 7 | @ifset INTERNALS |
| 8 | @node Machine Desc |
| 9 | @chapter Machine Descriptions |
| 10 | @cindex machine descriptions |
| 11 | |
| 12 | A machine description has two parts: a file of instruction patterns |
| 13 | (@file{.md} file) and a C header file of macro definitions. |
| 14 | |
| 15 | The @file{.md} file for a target machine contains a pattern for each |
| 16 | instruction that the target machine supports (or at least each instruction |
| 17 | that is worth telling the compiler about). It may also contain comments. |
| 18 | A semicolon causes the rest of the line to be a comment, unless the semicolon |
| 19 | is inside a quoted string. |
| 20 | |
| 21 | See the next chapter for information on the C header file. |
| 22 | |
| 23 | @menu |
| 24 | * Overview:: How the machine description is used. |
| 25 | * Patterns:: How to write instruction patterns. |
| 26 | * Example:: An explained example of a @code{define_insn} pattern. |
| 27 | * RTL Template:: The RTL template defines what insns match a pattern. |
| 28 | * Output Template:: The output template says how to make assembler code |
| 29 | from such an insn. |
| 30 | * Output Statement:: For more generality, write C code to output |
| 31 | the assembler code. |
| 32 | * Predicates:: Controlling what kinds of operands can be used |
| 33 | for an insn. |
| 34 | * Constraints:: Fine-tuning operand selection. |
| 35 | * Standard Names:: Names mark patterns to use for code generation. |
| 36 | * Pattern Ordering:: When the order of patterns makes a difference. |
| 37 | * Dependent Patterns:: Having one pattern may make you need another. |
| 38 | * Jump Patterns:: Special considerations for patterns for jump insns. |
| 39 | * Looping Patterns:: How to define patterns for special looping insns. |
| 40 | * Insn Canonicalizations::Canonicalization of Instructions |
| 41 | * Expander Definitions::Generating a sequence of several RTL insns |
| 42 | for a standard operation. |
| 43 | * Insn Splitting:: Splitting Instructions into Multiple Instructions. |
| 44 | * Including Patterns:: Including Patterns in Machine Descriptions. |
| 45 | * Peephole Definitions::Defining machine-specific peephole optimizations. |
| 46 | * Insn Attributes:: Specifying the value of attributes for generated insns. |
| 47 | * Conditional Execution::Generating @code{define_insn} patterns for |
| 48 | predication. |
| 49 | * Constant Definitions::Defining symbolic constants that can be used in the |
| 50 | md file. |
| 51 | * Iterators:: Using iterators to generate patterns from a template. |
| 52 | @end menu |
| 53 | |
| 54 | @node Overview |
| 55 | @section Overview of How the Machine Description is Used |
| 56 | |
| 57 | There are three main conversions that happen in the compiler: |
| 58 | |
| 59 | @enumerate |
| 60 | |
| 61 | @item |
| 62 | The front end reads the source code and builds a parse tree. |
| 63 | |
| 64 | @item |
| 65 | The parse tree is used to generate an RTL insn list based on named |
| 66 | instruction patterns. |
| 67 | |
| 68 | @item |
| 69 | The insn list is matched against the RTL templates to produce assembler |
| 70 | code. |
| 71 | |
| 72 | @end enumerate |
| 73 | |
| 74 | For the generate pass, only the names of the insns matter, from either a |
| 75 | named @code{define_insn} or a @code{define_expand}. The compiler will |
| 76 | choose the pattern with the right name and apply the operands according |
| 77 | to the documentation later in this chapter, without regard for the RTL |
| 78 | template or operand constraints. Note that the names the compiler looks |
| 79 | for are hard-coded in the compiler---it will ignore unnamed patterns and |
| 80 | patterns with names it doesn't know about, but if you don't provide a |
| 81 | named pattern it needs, it will abort. |
| 82 | |
| 83 | If a @code{define_insn} is used, the template given is inserted into the |
| 84 | insn list. If a @code{define_expand} is used, one of three things |
| 85 | happens, based on the condition logic. The condition logic may manually |
| 86 | create new insns for the insn list, say via @code{emit_insn()}, and |
| 87 | invoke @code{DONE}. For certain named patterns, it may invoke @code{FAIL} to tell the |
| 88 | compiler to use an alternate way of performing that task. If it invokes |
| 89 | neither @code{DONE} nor @code{FAIL}, the template given in the pattern |
| 90 | is inserted, as if the @code{define_expand} were a @code{define_insn}. |
| 91 | |
| 92 | Once the insn list is generated, various optimization passes convert, |
| 93 | replace, and rearrange the insns in the insn list. This is where the |
| 94 | @code{define_split} and @code{define_peephole} patterns get used, for |
| 95 | example. |
| 96 | |
| 97 | Finally, the insn list's RTL is matched up with the RTL templates in the |
| 98 | @code{define_insn} patterns, and those patterns are used to emit the |
| 99 | final assembly code. For this purpose, each named @code{define_insn} |
| 100 | acts like it's unnamed, since the names are ignored. |
| 101 | |
| 102 | @node Patterns |
| 103 | @section Everything about Instruction Patterns |
| 104 | @cindex patterns |
| 105 | @cindex instruction patterns |
| 106 | |
| 107 | @findex define_insn |
| 108 | Each instruction pattern contains an incomplete RTL expression, with pieces |
| 109 | to be filled in later, operand constraints that restrict how the pieces can |
| 110 | be filled in, and an output pattern or C code to generate the assembler |
| 111 | output, all wrapped up in a @code{define_insn} expression. |
| 112 | |
| 113 | A @code{define_insn} is an RTL expression containing four or five operands: |
| 114 | |
| 115 | @enumerate |
| 116 | @item |
| 117 | An optional name. The presence of a name indicate that this instruction |
| 118 | pattern can perform a certain standard job for the RTL-generation |
| 119 | pass of the compiler. This pass knows certain names and will use |
| 120 | the instruction patterns with those names, if the names are defined |
| 121 | in the machine description. |
| 122 | |
| 123 | The absence of a name is indicated by writing an empty string |
| 124 | where the name should go. Nameless instruction patterns are never |
| 125 | used for generating RTL code, but they may permit several simpler insns |
| 126 | to be combined later on. |
| 127 | |
| 128 | Names that are not thus known and used in RTL-generation have no |
| 129 | effect; they are equivalent to no name at all. |
| 130 | |
| 131 | For the purpose of debugging the compiler, you may also specify a |
| 132 | name beginning with the @samp{*} character. Such a name is used only |
| 133 | for identifying the instruction in RTL dumps; it is entirely equivalent |
| 134 | to having a nameless pattern for all other purposes. |
| 135 | |
| 136 | @item |
| 137 | The @dfn{RTL template} (@pxref{RTL Template}) is a vector of incomplete |
| 138 | RTL expressions which show what the instruction should look like. It is |
| 139 | incomplete because it may contain @code{match_operand}, |
| 140 | @code{match_operator}, and @code{match_dup} expressions that stand for |
| 141 | operands of the instruction. |
| 142 | |
| 143 | If the vector has only one element, that element is the template for the |
| 144 | instruction pattern. If the vector has multiple elements, then the |
| 145 | instruction pattern is a @code{parallel} expression containing the |
| 146 | elements described. |
| 147 | |
| 148 | @item |
| 149 | @cindex pattern conditions |
| 150 | @cindex conditions, in patterns |
| 151 | A condition. This is a string which contains a C expression that is |
| 152 | the final test to decide whether an insn body matches this pattern. |
| 153 | |
| 154 | @cindex named patterns and conditions |
| 155 | For a named pattern, the condition (if present) may not depend on |
| 156 | the data in the insn being matched, but only the target-machine-type |
| 157 | flags. The compiler needs to test these conditions during |
| 158 | initialization in order to learn exactly which named instructions are |
| 159 | available in a particular run. |
| 160 | |
| 161 | @findex operands |
| 162 | For nameless patterns, the condition is applied only when matching an |
| 163 | individual insn, and only after the insn has matched the pattern's |
| 164 | recognition template. The insn's operands may be found in the vector |
| 165 | @code{operands}. For an insn where the condition has once matched, it |
| 166 | can't be used to control register allocation, for example by excluding |
| 167 | certain hard registers or hard register combinations. |
| 168 | |
| 169 | @item |
| 170 | The @dfn{output template}: a string that says how to output matching |
| 171 | insns as assembler code. @samp{%} in this string specifies where |
| 172 | to substitute the value of an operand. @xref{Output Template}. |
| 173 | |
| 174 | When simple substitution isn't general enough, you can specify a piece |
| 175 | of C code to compute the output. @xref{Output Statement}. |
| 176 | |
| 177 | @item |
| 178 | Optionally, a vector containing the values of attributes for insns matching |
| 179 | this pattern. @xref{Insn Attributes}. |
| 180 | @end enumerate |
| 181 | |
| 182 | @node Example |
| 183 | @section Example of @code{define_insn} |
| 184 | @cindex @code{define_insn} example |
| 185 | |
| 186 | Here is an actual example of an instruction pattern, for the 68000/68020. |
| 187 | |
| 188 | @smallexample |
| 189 | (define_insn "tstsi" |
| 190 | [(set (cc0) |
| 191 | (match_operand:SI 0 "general_operand" "rm"))] |
| 192 | "" |
| 193 | "* |
| 194 | @{ |
| 195 | if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) |
| 196 | return \"tstl %0\"; |
| 197 | return \"cmpl #0,%0\"; |
| 198 | @}") |
| 199 | @end smallexample |
| 200 | |
| 201 | @noindent |
| 202 | This can also be written using braced strings: |
| 203 | |
| 204 | @smallexample |
| 205 | (define_insn "tstsi" |
| 206 | [(set (cc0) |
| 207 | (match_operand:SI 0 "general_operand" "rm"))] |
| 208 | "" |
| 209 | @{ |
| 210 | if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) |
| 211 | return "tstl %0"; |
| 212 | return "cmpl #0,%0"; |
| 213 | @}) |
| 214 | @end smallexample |
| 215 | |
| 216 | This is an instruction that sets the condition codes based on the value of |
| 217 | a general operand. It has no condition, so any insn whose RTL description |
| 218 | has the form shown may be handled according to this pattern. The name |
| 219 | @samp{tstsi} means ``test a @code{SImode} value'' and tells the RTL generation |
| 220 | pass that, when it is necessary to test such a value, an insn to do so |
| 221 | can be constructed using this pattern. |
| 222 | |
| 223 | The output control string is a piece of C code which chooses which |
| 224 | output template to return based on the kind of operand and the specific |
| 225 | type of CPU for which code is being generated. |
| 226 | |
| 227 | @samp{"rm"} is an operand constraint. Its meaning is explained below. |
| 228 | |
| 229 | @node RTL Template |
| 230 | @section RTL Template |
| 231 | @cindex RTL insn template |
| 232 | @cindex generating insns |
| 233 | @cindex insns, generating |
| 234 | @cindex recognizing insns |
| 235 | @cindex insns, recognizing |
| 236 | |
| 237 | The RTL template is used to define which insns match the particular pattern |
| 238 | and how to find their operands. For named patterns, the RTL template also |
| 239 | says how to construct an insn from specified operands. |
| 240 | |
| 241 | Construction involves substituting specified operands into a copy of the |
| 242 | template. Matching involves determining the values that serve as the |
| 243 | operands in the insn being matched. Both of these activities are |
| 244 | controlled by special expression types that direct matching and |
| 245 | substitution of the operands. |
| 246 | |
| 247 | @table @code |
| 248 | @findex match_operand |
| 249 | @item (match_operand:@var{m} @var{n} @var{predicate} @var{constraint}) |
| 250 | This expression is a placeholder for operand number @var{n} of |
| 251 | the insn. When constructing an insn, operand number @var{n} |
| 252 | will be substituted at this point. When matching an insn, whatever |
| 253 | appears at this position in the insn will be taken as operand |
| 254 | number @var{n}; but it must satisfy @var{predicate} or this instruction |
| 255 | pattern will not match at all. |
| 256 | |
| 257 | Operand numbers must be chosen consecutively counting from zero in |
| 258 | each instruction pattern. There may be only one @code{match_operand} |
| 259 | expression in the pattern for each operand number. Usually operands |
| 260 | are numbered in the order of appearance in @code{match_operand} |
| 261 | expressions. In the case of a @code{define_expand}, any operand numbers |
| 262 | used only in @code{match_dup} expressions have higher values than all |
| 263 | other operand numbers. |
| 264 | |
| 265 | @var{predicate} is a string that is the name of a function that |
| 266 | accepts two arguments, an expression and a machine mode. |
| 267 | @xref{Predicates}. During matching, the function will be called with |
| 268 | the putative operand as the expression and @var{m} as the mode |
| 269 | argument (if @var{m} is not specified, @code{VOIDmode} will be used, |
| 270 | which normally causes @var{predicate} to accept any mode). If it |
| 271 | returns zero, this instruction pattern fails to match. |
| 272 | @var{predicate} may be an empty string; then it means no test is to be |
| 273 | done on the operand, so anything which occurs in this position is |
| 274 | valid. |
| 275 | |
| 276 | Most of the time, @var{predicate} will reject modes other than @var{m}---but |
| 277 | not always. For example, the predicate @code{address_operand} uses |
| 278 | @var{m} as the mode of memory ref that the address should be valid for. |
| 279 | Many predicates accept @code{const_int} nodes even though their mode is |
| 280 | @code{VOIDmode}. |
| 281 | |
| 282 | @var{constraint} controls reloading and the choice of the best register |
| 283 | class to use for a value, as explained later (@pxref{Constraints}). |
| 284 | If the constraint would be an empty string, it can be omitted. |
| 285 | |
| 286 | People are often unclear on the difference between the constraint and the |
| 287 | predicate. The predicate helps decide whether a given insn matches the |
| 288 | pattern. The constraint plays no role in this decision; instead, it |
| 289 | controls various decisions in the case of an insn which does match. |
| 290 | |
| 291 | @findex match_scratch |
| 292 | @item (match_scratch:@var{m} @var{n} @var{constraint}) |
| 293 | This expression is also a placeholder for operand number @var{n} |
| 294 | and indicates that operand must be a @code{scratch} or @code{reg} |
| 295 | expression. |
| 296 | |
| 297 | When matching patterns, this is equivalent to |
| 298 | |
| 299 | @smallexample |
| 300 | (match_operand:@var{m} @var{n} "scratch_operand" @var{pred}) |
| 301 | @end smallexample |
| 302 | |
| 303 | but, when generating RTL, it produces a (@code{scratch}:@var{m}) |
| 304 | expression. |
| 305 | |
| 306 | If the last few expressions in a @code{parallel} are @code{clobber} |
| 307 | expressions whose operands are either a hard register or |
| 308 | @code{match_scratch}, the combiner can add or delete them when |
| 309 | necessary. @xref{Side Effects}. |
| 310 | |
| 311 | @findex match_dup |
| 312 | @item (match_dup @var{n}) |
| 313 | This expression is also a placeholder for operand number @var{n}. |
| 314 | It is used when the operand needs to appear more than once in the |
| 315 | insn. |
| 316 | |
| 317 | In construction, @code{match_dup} acts just like @code{match_operand}: |
| 318 | the operand is substituted into the insn being constructed. But in |
| 319 | matching, @code{match_dup} behaves differently. It assumes that operand |
| 320 | number @var{n} has already been determined by a @code{match_operand} |
| 321 | appearing earlier in the recognition template, and it matches only an |
| 322 | identical-looking expression. |
| 323 | |
| 324 | Note that @code{match_dup} should not be used to tell the compiler that |
| 325 | a particular register is being used for two operands (example: |
| 326 | @code{add} that adds one register to another; the second register is |
| 327 | both an input operand and the output operand). Use a matching |
| 328 | constraint (@pxref{Simple Constraints}) for those. @code{match_dup} is for the cases where one |
| 329 | operand is used in two places in the template, such as an instruction |
| 330 | that computes both a quotient and a remainder, where the opcode takes |
| 331 | two input operands but the RTL template has to refer to each of those |
| 332 | twice; once for the quotient pattern and once for the remainder pattern. |
| 333 | |
| 334 | @findex match_operator |
| 335 | @item (match_operator:@var{m} @var{n} @var{predicate} [@var{operands}@dots{}]) |
| 336 | This pattern is a kind of placeholder for a variable RTL expression |
| 337 | code. |
| 338 | |
| 339 | When constructing an insn, it stands for an RTL expression whose |
| 340 | expression code is taken from that of operand @var{n}, and whose |
| 341 | operands are constructed from the patterns @var{operands}. |
| 342 | |
| 343 | When matching an expression, it matches an expression if the function |
| 344 | @var{predicate} returns nonzero on that expression @emph{and} the |
| 345 | patterns @var{operands} match the operands of the expression. |
| 346 | |
| 347 | Suppose that the function @code{commutative_operator} is defined as |
| 348 | follows, to match any expression whose operator is one of the |
| 349 | commutative arithmetic operators of RTL and whose mode is @var{mode}: |
| 350 | |
| 351 | @smallexample |
| 352 | int |
| 353 | commutative_integer_operator (x, mode) |
| 354 | rtx x; |
| 355 | enum machine_mode mode; |
| 356 | @{ |
| 357 | enum rtx_code code = GET_CODE (x); |
| 358 | if (GET_MODE (x) != mode) |
| 359 | return 0; |
| 360 | return (GET_RTX_CLASS (code) == RTX_COMM_ARITH |
| 361 | || code == EQ || code == NE); |
| 362 | @} |
| 363 | @end smallexample |
| 364 | |
| 365 | Then the following pattern will match any RTL expression consisting |
| 366 | of a commutative operator applied to two general operands: |
| 367 | |
| 368 | @smallexample |
| 369 | (match_operator:SI 3 "commutative_operator" |
| 370 | [(match_operand:SI 1 "general_operand" "g") |
| 371 | (match_operand:SI 2 "general_operand" "g")]) |
| 372 | @end smallexample |
| 373 | |
| 374 | Here the vector @code{[@var{operands}@dots{}]} contains two patterns |
| 375 | because the expressions to be matched all contain two operands. |
| 376 | |
| 377 | When this pattern does match, the two operands of the commutative |
| 378 | operator are recorded as operands 1 and 2 of the insn. (This is done |
| 379 | by the two instances of @code{match_operand}.) Operand 3 of the insn |
| 380 | will be the entire commutative expression: use @code{GET_CODE |
| 381 | (operands[3])} to see which commutative operator was used. |
| 382 | |
| 383 | The machine mode @var{m} of @code{match_operator} works like that of |
| 384 | @code{match_operand}: it is passed as the second argument to the |
| 385 | predicate function, and that function is solely responsible for |
| 386 | deciding whether the expression to be matched ``has'' that mode. |
| 387 | |
| 388 | When constructing an insn, argument 3 of the gen-function will specify |
| 389 | the operation (i.e.@: the expression code) for the expression to be |
| 390 | made. It should be an RTL expression, whose expression code is copied |
| 391 | into a new expression whose operands are arguments 1 and 2 of the |
| 392 | gen-function. The subexpressions of argument 3 are not used; |
| 393 | only its expression code matters. |
| 394 | |
| 395 | When @code{match_operator} is used in a pattern for matching an insn, |
| 396 | it usually best if the operand number of the @code{match_operator} |
| 397 | is higher than that of the actual operands of the insn. This improves |
| 398 | register allocation because the register allocator often looks at |
| 399 | operands 1 and 2 of insns to see if it can do register tying. |
| 400 | |
| 401 | There is no way to specify constraints in @code{match_operator}. The |
| 402 | operand of the insn which corresponds to the @code{match_operator} |
| 403 | never has any constraints because it is never reloaded as a whole. |
| 404 | However, if parts of its @var{operands} are matched by |
| 405 | @code{match_operand} patterns, those parts may have constraints of |
| 406 | their own. |
| 407 | |
| 408 | @findex match_op_dup |
| 409 | @item (match_op_dup:@var{m} @var{n}[@var{operands}@dots{}]) |
| 410 | Like @code{match_dup}, except that it applies to operators instead of |
| 411 | operands. When constructing an insn, operand number @var{n} will be |
| 412 | substituted at this point. But in matching, @code{match_op_dup} behaves |
| 413 | differently. It assumes that operand number @var{n} has already been |
| 414 | determined by a @code{match_operator} appearing earlier in the |
| 415 | recognition template, and it matches only an identical-looking |
| 416 | expression. |
| 417 | |
| 418 | @findex match_parallel |
| 419 | @item (match_parallel @var{n} @var{predicate} [@var{subpat}@dots{}]) |
| 420 | This pattern is a placeholder for an insn that consists of a |
| 421 | @code{parallel} expression with a variable number of elements. This |
| 422 | expression should only appear at the top level of an insn pattern. |
| 423 | |
| 424 | When constructing an insn, operand number @var{n} will be substituted at |
| 425 | this point. When matching an insn, it matches if the body of the insn |
| 426 | is a @code{parallel} expression with at least as many elements as the |
| 427 | vector of @var{subpat} expressions in the @code{match_parallel}, if each |
| 428 | @var{subpat} matches the corresponding element of the @code{parallel}, |
| 429 | @emph{and} the function @var{predicate} returns nonzero on the |
| 430 | @code{parallel} that is the body of the insn. It is the responsibility |
| 431 | of the predicate to validate elements of the @code{parallel} beyond |
| 432 | those listed in the @code{match_parallel}. |
| 433 | |
| 434 | A typical use of @code{match_parallel} is to match load and store |
| 435 | multiple expressions, which can contain a variable number of elements |
| 436 | in a @code{parallel}. For example, |
| 437 | |
| 438 | @smallexample |
| 439 | (define_insn "" |
| 440 | [(match_parallel 0 "load_multiple_operation" |
| 441 | [(set (match_operand:SI 1 "gpc_reg_operand" "=r") |
| 442 | (match_operand:SI 2 "memory_operand" "m")) |
| 443 | (use (reg:SI 179)) |
| 444 | (clobber (reg:SI 179))])] |
| 445 | "" |
| 446 | "loadm 0,0,%1,%2") |
| 447 | @end smallexample |
| 448 | |
| 449 | This example comes from @file{a29k.md}. The function |
| 450 | @code{load_multiple_operation} is defined in @file{a29k.c} and checks |
| 451 | that subsequent elements in the @code{parallel} are the same as the |
| 452 | @code{set} in the pattern, except that they are referencing subsequent |
| 453 | registers and memory locations. |
| 454 | |
| 455 | An insn that matches this pattern might look like: |
| 456 | |
| 457 | @smallexample |
| 458 | (parallel |
| 459 | [(set (reg:SI 20) (mem:SI (reg:SI 100))) |
| 460 | (use (reg:SI 179)) |
| 461 | (clobber (reg:SI 179)) |
| 462 | (set (reg:SI 21) |
| 463 | (mem:SI (plus:SI (reg:SI 100) |
| 464 | (const_int 4)))) |
| 465 | (set (reg:SI 22) |
| 466 | (mem:SI (plus:SI (reg:SI 100) |
| 467 | (const_int 8))))]) |
| 468 | @end smallexample |
| 469 | |
| 470 | @findex match_par_dup |
| 471 | @item (match_par_dup @var{n} [@var{subpat}@dots{}]) |
| 472 | Like @code{match_op_dup}, but for @code{match_parallel} instead of |
| 473 | @code{match_operator}. |
| 474 | |
| 475 | @end table |
| 476 | |
| 477 | @node Output Template |
| 478 | @section Output Templates and Operand Substitution |
| 479 | @cindex output templates |
| 480 | @cindex operand substitution |
| 481 | |
| 482 | @cindex @samp{%} in template |
| 483 | @cindex percent sign |
| 484 | The @dfn{output template} is a string which specifies how to output the |
| 485 | assembler code for an instruction pattern. Most of the template is a |
| 486 | fixed string which is output literally. The character @samp{%} is used |
| 487 | to specify where to substitute an operand; it can also be used to |
| 488 | identify places where different variants of the assembler require |
| 489 | different syntax. |
| 490 | |
| 491 | In the simplest case, a @samp{%} followed by a digit @var{n} says to output |
| 492 | operand @var{n} at that point in the string. |
| 493 | |
| 494 | @samp{%} followed by a letter and a digit says to output an operand in an |
| 495 | alternate fashion. Four letters have standard, built-in meanings described |
| 496 | below. The machine description macro @code{PRINT_OPERAND} can define |
| 497 | additional letters with nonstandard meanings. |
| 498 | |
| 499 | @samp{%c@var{digit}} can be used to substitute an operand that is a |
| 500 | constant value without the syntax that normally indicates an immediate |
| 501 | operand. |
| 502 | |
| 503 | @samp{%n@var{digit}} is like @samp{%c@var{digit}} except that the value of |
| 504 | the constant is negated before printing. |
| 505 | |
| 506 | @samp{%a@var{digit}} can be used to substitute an operand as if it were a |
| 507 | memory reference, with the actual operand treated as the address. This may |
| 508 | be useful when outputting a ``load address'' instruction, because often the |
| 509 | assembler syntax for such an instruction requires you to write the operand |
| 510 | as if it were a memory reference. |
| 511 | |
| 512 | @samp{%l@var{digit}} is used to substitute a @code{label_ref} into a jump |
| 513 | instruction. |
| 514 | |
| 515 | @samp{%=} outputs a number which is unique to each instruction in the |
| 516 | entire compilation. This is useful for making local labels to be |
| 517 | referred to more than once in a single template that generates multiple |
| 518 | assembler instructions. |
| 519 | |
| 520 | @samp{%} followed by a punctuation character specifies a substitution that |
| 521 | does not use an operand. Only one case is standard: @samp{%%} outputs a |
| 522 | @samp{%} into the assembler code. Other nonstandard cases can be |
| 523 | defined in the @code{PRINT_OPERAND} macro. You must also define |
| 524 | which punctuation characters are valid with the |
| 525 | @code{PRINT_OPERAND_PUNCT_VALID_P} macro. |
| 526 | |
| 527 | @cindex \ |
| 528 | @cindex backslash |
| 529 | The template may generate multiple assembler instructions. Write the text |
| 530 | for the instructions, with @samp{\;} between them. |
| 531 | |
| 532 | @cindex matching operands |
| 533 | When the RTL contains two operands which are required by constraint to match |
| 534 | each other, the output template must refer only to the lower-numbered operand. |
| 535 | Matching operands are not always identical, and the rest of the compiler |
| 536 | arranges to put the proper RTL expression for printing into the lower-numbered |
| 537 | operand. |
| 538 | |
| 539 | One use of nonstandard letters or punctuation following @samp{%} is to |
| 540 | distinguish between different assembler languages for the same machine; for |
| 541 | example, Motorola syntax versus MIT syntax for the 68000. Motorola syntax |
| 542 | requires periods in most opcode names, while MIT syntax does not. For |
| 543 | example, the opcode @samp{movel} in MIT syntax is @samp{move.l} in Motorola |
| 544 | syntax. The same file of patterns is used for both kinds of output syntax, |
| 545 | but the character sequence @samp{%.} is used in each place where Motorola |
| 546 | syntax wants a period. The @code{PRINT_OPERAND} macro for Motorola syntax |
| 547 | defines the sequence to output a period; the macro for MIT syntax defines |
| 548 | it to do nothing. |
| 549 | |
| 550 | @cindex @code{#} in template |
| 551 | As a special case, a template consisting of the single character @code{#} |
| 552 | instructs the compiler to first split the insn, and then output the |
| 553 | resulting instructions separately. This helps eliminate redundancy in the |
| 554 | output templates. If you have a @code{define_insn} that needs to emit |
| 555 | multiple assembler instructions, and there is a matching @code{define_split} |
| 556 | already defined, then you can simply use @code{#} as the output template |
| 557 | instead of writing an output template that emits the multiple assembler |
| 558 | instructions. |
| 559 | |
| 560 | If the macro @code{ASSEMBLER_DIALECT} is defined, you can use construct |
| 561 | of the form @samp{@{option0|option1|option2@}} in the templates. These |
| 562 | describe multiple variants of assembler language syntax. |
| 563 | @xref{Instruction Output}. |
| 564 | |
| 565 | @node Output Statement |
| 566 | @section C Statements for Assembler Output |
| 567 | @cindex output statements |
| 568 | @cindex C statements for assembler output |
| 569 | @cindex generating assembler output |
| 570 | |
| 571 | Often a single fixed template string cannot produce correct and efficient |
| 572 | assembler code for all the cases that are recognized by a single |
| 573 | instruction pattern. For example, the opcodes may depend on the kinds of |
| 574 | operands; or some unfortunate combinations of operands may require extra |
| 575 | machine instructions. |
| 576 | |
| 577 | If the output control string starts with a @samp{@@}, then it is actually |
| 578 | a series of templates, each on a separate line. (Blank lines and |
| 579 | leading spaces and tabs are ignored.) The templates correspond to the |
| 580 | pattern's constraint alternatives (@pxref{Multi-Alternative}). For example, |
| 581 | if a target machine has a two-address add instruction @samp{addr} to add |
| 582 | into a register and another @samp{addm} to add a register to memory, you |
| 583 | might write this pattern: |
| 584 | |
| 585 | @smallexample |
| 586 | (define_insn "addsi3" |
| 587 | [(set (match_operand:SI 0 "general_operand" "=r,m") |
| 588 | (plus:SI (match_operand:SI 1 "general_operand" "0,0") |
| 589 | (match_operand:SI 2 "general_operand" "g,r")))] |
| 590 | "" |
| 591 | "@@ |
| 592 | addr %2,%0 |
| 593 | addm %2,%0") |
| 594 | @end smallexample |
| 595 | |
| 596 | @cindex @code{*} in template |
| 597 | @cindex asterisk in template |
| 598 | If the output control string starts with a @samp{*}, then it is not an |
| 599 | output template but rather a piece of C program that should compute a |
| 600 | template. It should execute a @code{return} statement to return the |
| 601 | template-string you want. Most such templates use C string literals, which |
| 602 | require doublequote characters to delimit them. To include these |
| 603 | doublequote characters in the string, prefix each one with @samp{\}. |
| 604 | |
| 605 | If the output control string is written as a brace block instead of a |
| 606 | double-quoted string, it is automatically assumed to be C code. In that |
| 607 | case, it is not necessary to put in a leading asterisk, or to escape the |
| 608 | doublequotes surrounding C string literals. |
| 609 | |
| 610 | The operands may be found in the array @code{operands}, whose C data type |
| 611 | is @code{rtx []}. |
| 612 | |
| 613 | It is very common to select different ways of generating assembler code |
| 614 | based on whether an immediate operand is within a certain range. Be |
| 615 | careful when doing this, because the result of @code{INTVAL} is an |
| 616 | integer on the host machine. If the host machine has more bits in an |
| 617 | @code{int} than the target machine has in the mode in which the constant |
| 618 | will be used, then some of the bits you get from @code{INTVAL} will be |
| 619 | superfluous. For proper results, you must carefully disregard the |
| 620 | values of those bits. |
| 621 | |
| 622 | @findex output_asm_insn |
| 623 | It is possible to output an assembler instruction and then go on to output |
| 624 | or compute more of them, using the subroutine @code{output_asm_insn}. This |
| 625 | receives two arguments: a template-string and a vector of operands. The |
| 626 | vector may be @code{operands}, or it may be another array of @code{rtx} |
| 627 | that you declare locally and initialize yourself. |
| 628 | |
| 629 | @findex which_alternative |
| 630 | When an insn pattern has multiple alternatives in its constraints, often |
| 631 | the appearance of the assembler code is determined mostly by which alternative |
| 632 | was matched. When this is so, the C code can test the variable |
| 633 | @code{which_alternative}, which is the ordinal number of the alternative |
| 634 | that was actually satisfied (0 for the first, 1 for the second alternative, |
| 635 | etc.). |
| 636 | |
| 637 | For example, suppose there are two opcodes for storing zero, @samp{clrreg} |
| 638 | for registers and @samp{clrmem} for memory locations. Here is how |
| 639 | a pattern could use @code{which_alternative} to choose between them: |
| 640 | |
| 641 | @smallexample |
| 642 | (define_insn "" |
| 643 | [(set (match_operand:SI 0 "general_operand" "=r,m") |
| 644 | (const_int 0))] |
| 645 | "" |
| 646 | @{ |
| 647 | return (which_alternative == 0 |
| 648 | ? "clrreg %0" : "clrmem %0"); |
| 649 | @}) |
| 650 | @end smallexample |
| 651 | |
| 652 | The example above, where the assembler code to generate was |
| 653 | @emph{solely} determined by the alternative, could also have been specified |
| 654 | as follows, having the output control string start with a @samp{@@}: |
| 655 | |
| 656 | @smallexample |
| 657 | @group |
| 658 | (define_insn "" |
| 659 | [(set (match_operand:SI 0 "general_operand" "=r,m") |
| 660 | (const_int 0))] |
| 661 | "" |
| 662 | "@@ |
| 663 | clrreg %0 |
| 664 | clrmem %0") |
| 665 | @end group |
| 666 | @end smallexample |
| 667 | |
Bernhard Rosenkraenzer | 7d3ad0b | 2012-10-23 01:39:53 +0159 | [diff] [blame^] | 668 | If you just need a little bit of C code in one (or a few) alternatives, |
| 669 | you can use @samp{*} inside of a @samp{@@} multi-alternative template: |
| 670 | |
| 671 | @smallexample |
| 672 | @group |
| 673 | (define_insn "" |
| 674 | [(set (match_operand:SI 0 "general_operand" "=r,<,m") |
| 675 | (const_int 0))] |
| 676 | "" |
| 677 | "@@ |
| 678 | clrreg %0 |
| 679 | * return stack_mem_p (operands[0]) ? \"push 0\" : \"clrmem %0\"; |
| 680 | clrmem %0") |
| 681 | @end group |
| 682 | @end smallexample |
| 683 | |
Bernhard Rosenkraenzer | c83ebe5 | 2012-09-18 21:38:03 +0159 | [diff] [blame] | 684 | @node Predicates |
| 685 | @section Predicates |
| 686 | @cindex predicates |
| 687 | @cindex operand predicates |
| 688 | @cindex operator predicates |
| 689 | |
| 690 | A predicate determines whether a @code{match_operand} or |
| 691 | @code{match_operator} expression matches, and therefore whether the |
| 692 | surrounding instruction pattern will be used for that combination of |
| 693 | operands. GCC has a number of machine-independent predicates, and you |
| 694 | can define machine-specific predicates as needed. By convention, |
| 695 | predicates used with @code{match_operand} have names that end in |
| 696 | @samp{_operand}, and those used with @code{match_operator} have names |
| 697 | that end in @samp{_operator}. |
| 698 | |
| 699 | All predicates are Boolean functions (in the mathematical sense) of |
| 700 | two arguments: the RTL expression that is being considered at that |
| 701 | position in the instruction pattern, and the machine mode that the |
| 702 | @code{match_operand} or @code{match_operator} specifies. In this |
| 703 | section, the first argument is called @var{op} and the second argument |
| 704 | @var{mode}. Predicates can be called from C as ordinary two-argument |
| 705 | functions; this can be useful in output templates or other |
| 706 | machine-specific code. |
| 707 | |
| 708 | Operand predicates can allow operands that are not actually acceptable |
| 709 | to the hardware, as long as the constraints give reload the ability to |
| 710 | fix them up (@pxref{Constraints}). However, GCC will usually generate |
| 711 | better code if the predicates specify the requirements of the machine |
| 712 | instructions as closely as possible. Reload cannot fix up operands |
| 713 | that must be constants (``immediate operands''); you must use a |
| 714 | predicate that allows only constants, or else enforce the requirement |
| 715 | in the extra condition. |
| 716 | |
| 717 | @cindex predicates and machine modes |
| 718 | @cindex normal predicates |
| 719 | @cindex special predicates |
| 720 | Most predicates handle their @var{mode} argument in a uniform manner. |
| 721 | If @var{mode} is @code{VOIDmode} (unspecified), then @var{op} can have |
| 722 | any mode. If @var{mode} is anything else, then @var{op} must have the |
| 723 | same mode, unless @var{op} is a @code{CONST_INT} or integer |
| 724 | @code{CONST_DOUBLE}. These RTL expressions always have |
| 725 | @code{VOIDmode}, so it would be counterproductive to check that their |
| 726 | mode matches. Instead, predicates that accept @code{CONST_INT} and/or |
| 727 | integer @code{CONST_DOUBLE} check that the value stored in the |
| 728 | constant will fit in the requested mode. |
| 729 | |
| 730 | Predicates with this behavior are called @dfn{normal}. |
| 731 | @command{genrecog} can optimize the instruction recognizer based on |
| 732 | knowledge of how normal predicates treat modes. It can also diagnose |
| 733 | certain kinds of common errors in the use of normal predicates; for |
| 734 | instance, it is almost always an error to use a normal predicate |
| 735 | without specifying a mode. |
| 736 | |
| 737 | Predicates that do something different with their @var{mode} argument |
| 738 | are called @dfn{special}. The generic predicates |
| 739 | @code{address_operand} and @code{pmode_register_operand} are special |
| 740 | predicates. @command{genrecog} does not do any optimizations or |
| 741 | diagnosis when special predicates are used. |
| 742 | |
| 743 | @menu |
| 744 | * Machine-Independent Predicates:: Predicates available to all back ends. |
| 745 | * Defining Predicates:: How to write machine-specific predicate |
| 746 | functions. |
| 747 | @end menu |
| 748 | |
| 749 | @node Machine-Independent Predicates |
| 750 | @subsection Machine-Independent Predicates |
| 751 | @cindex machine-independent predicates |
| 752 | @cindex generic predicates |
| 753 | |
| 754 | These are the generic predicates available to all back ends. They are |
| 755 | defined in @file{recog.c}. The first category of predicates allow |
| 756 | only constant, or @dfn{immediate}, operands. |
| 757 | |
| 758 | @defun immediate_operand |
| 759 | This predicate allows any sort of constant that fits in @var{mode}. |
| 760 | It is an appropriate choice for instructions that take operands that |
| 761 | must be constant. |
| 762 | @end defun |
| 763 | |
| 764 | @defun const_int_operand |
| 765 | This predicate allows any @code{CONST_INT} expression that fits in |
| 766 | @var{mode}. It is an appropriate choice for an immediate operand that |
| 767 | does not allow a symbol or label. |
| 768 | @end defun |
| 769 | |
| 770 | @defun const_double_operand |
| 771 | This predicate accepts any @code{CONST_DOUBLE} expression that has |
| 772 | exactly @var{mode}. If @var{mode} is @code{VOIDmode}, it will also |
| 773 | accept @code{CONST_INT}. It is intended for immediate floating point |
| 774 | constants. |
| 775 | @end defun |
| 776 | |
| 777 | @noindent |
| 778 | The second category of predicates allow only some kind of machine |
| 779 | register. |
| 780 | |
| 781 | @defun register_operand |
| 782 | This predicate allows any @code{REG} or @code{SUBREG} expression that |
| 783 | is valid for @var{mode}. It is often suitable for arithmetic |
| 784 | instruction operands on a RISC machine. |
| 785 | @end defun |
| 786 | |
| 787 | @defun pmode_register_operand |
| 788 | This is a slight variant on @code{register_operand} which works around |
| 789 | a limitation in the machine-description reader. |
| 790 | |
| 791 | @smallexample |
| 792 | (match_operand @var{n} "pmode_register_operand" @var{constraint}) |
| 793 | @end smallexample |
| 794 | |
| 795 | @noindent |
| 796 | means exactly what |
| 797 | |
| 798 | @smallexample |
| 799 | (match_operand:P @var{n} "register_operand" @var{constraint}) |
| 800 | @end smallexample |
| 801 | |
| 802 | @noindent |
| 803 | would mean, if the machine-description reader accepted @samp{:P} |
| 804 | mode suffixes. Unfortunately, it cannot, because @code{Pmode} is an |
| 805 | alias for some other mode, and might vary with machine-specific |
| 806 | options. @xref{Misc}. |
| 807 | @end defun |
| 808 | |
| 809 | @defun scratch_operand |
| 810 | This predicate allows hard registers and @code{SCRATCH} expressions, |
| 811 | but not pseudo-registers. It is used internally by @code{match_scratch}; |
| 812 | it should not be used directly. |
| 813 | @end defun |
| 814 | |
| 815 | @noindent |
| 816 | The third category of predicates allow only some kind of memory reference. |
| 817 | |
| 818 | @defun memory_operand |
| 819 | This predicate allows any valid reference to a quantity of mode |
| 820 | @var{mode} in memory, as determined by the weak form of |
| 821 | @code{GO_IF_LEGITIMATE_ADDRESS} (@pxref{Addressing Modes}). |
| 822 | @end defun |
| 823 | |
| 824 | @defun address_operand |
| 825 | This predicate is a little unusual; it allows any operand that is a |
| 826 | valid expression for the @emph{address} of a quantity of mode |
| 827 | @var{mode}, again determined by the weak form of |
| 828 | @code{GO_IF_LEGITIMATE_ADDRESS}. To first order, if |
| 829 | @samp{@w{(mem:@var{mode} (@var{exp}))}} is acceptable to |
| 830 | @code{memory_operand}, then @var{exp} is acceptable to |
| 831 | @code{address_operand}. Note that @var{exp} does not necessarily have |
| 832 | the mode @var{mode}. |
| 833 | @end defun |
| 834 | |
| 835 | @defun indirect_operand |
| 836 | This is a stricter form of @code{memory_operand} which allows only |
| 837 | memory references with a @code{general_operand} as the address |
| 838 | expression. New uses of this predicate are discouraged, because |
| 839 | @code{general_operand} is very permissive, so it's hard to tell what |
| 840 | an @code{indirect_operand} does or does not allow. If a target has |
| 841 | different requirements for memory operands for different instructions, |
| 842 | it is better to define target-specific predicates which enforce the |
| 843 | hardware's requirements explicitly. |
| 844 | @end defun |
| 845 | |
| 846 | @defun push_operand |
| 847 | This predicate allows a memory reference suitable for pushing a value |
| 848 | onto the stack. This will be a @code{MEM} which refers to |
| 849 | @code{stack_pointer_rtx}, with a side-effect in its address expression |
| 850 | (@pxref{Incdec}); which one is determined by the |
| 851 | @code{STACK_PUSH_CODE} macro (@pxref{Frame Layout}). |
| 852 | @end defun |
| 853 | |
| 854 | @defun pop_operand |
| 855 | This predicate allows a memory reference suitable for popping a value |
| 856 | off the stack. Again, this will be a @code{MEM} referring to |
| 857 | @code{stack_pointer_rtx}, with a side-effect in its address |
| 858 | expression. However, this time @code{STACK_POP_CODE} is expected. |
| 859 | @end defun |
| 860 | |
| 861 | @noindent |
| 862 | The fourth category of predicates allow some combination of the above |
| 863 | operands. |
| 864 | |
| 865 | @defun nonmemory_operand |
| 866 | This predicate allows any immediate or register operand valid for @var{mode}. |
| 867 | @end defun |
| 868 | |
| 869 | @defun nonimmediate_operand |
| 870 | This predicate allows any register or memory operand valid for @var{mode}. |
| 871 | @end defun |
| 872 | |
| 873 | @defun general_operand |
| 874 | This predicate allows any immediate, register, or memory operand |
| 875 | valid for @var{mode}. |
| 876 | @end defun |
| 877 | |
| 878 | @noindent |
| 879 | Finally, there are two generic operator predicates. |
| 880 | |
| 881 | @defun comparison_operator |
| 882 | This predicate matches any expression which performs an arithmetic |
| 883 | comparison in @var{mode}; that is, @code{COMPARISON_P} is true for the |
| 884 | expression code. |
| 885 | @end defun |
| 886 | |
| 887 | @defun ordered_comparison_operator |
| 888 | This predicate matches any expression which performs an arithmetic |
| 889 | comparison in @var{mode} and whose expression code is valid for integer |
| 890 | modes; that is, the expression code will be one of @code{eq}, @code{ne}, |
| 891 | @code{lt}, @code{ltu}, @code{le}, @code{leu}, @code{gt}, @code{gtu}, |
| 892 | @code{ge}, @code{geu}. |
| 893 | @end defun |
| 894 | |
| 895 | @node Defining Predicates |
| 896 | @subsection Defining Machine-Specific Predicates |
| 897 | @cindex defining predicates |
| 898 | @findex define_predicate |
| 899 | @findex define_special_predicate |
| 900 | |
| 901 | Many machines have requirements for their operands that cannot be |
| 902 | expressed precisely using the generic predicates. You can define |
| 903 | additional predicates using @code{define_predicate} and |
| 904 | @code{define_special_predicate} expressions. These expressions have |
| 905 | three operands: |
| 906 | |
| 907 | @itemize @bullet |
| 908 | @item |
| 909 | The name of the predicate, as it will be referred to in |
| 910 | @code{match_operand} or @code{match_operator} expressions. |
| 911 | |
| 912 | @item |
| 913 | An RTL expression which evaluates to true if the predicate allows the |
| 914 | operand @var{op}, false if it does not. This expression can only use |
| 915 | the following RTL codes: |
| 916 | |
| 917 | @table @code |
| 918 | @item MATCH_OPERAND |
| 919 | When written inside a predicate expression, a @code{MATCH_OPERAND} |
| 920 | expression evaluates to true if the predicate it names would allow |
| 921 | @var{op}. The operand number and constraint are ignored. Due to |
| 922 | limitations in @command{genrecog}, you can only refer to generic |
| 923 | predicates and predicates that have already been defined. |
| 924 | |
| 925 | @item MATCH_CODE |
| 926 | This expression evaluates to true if @var{op} or a specified |
| 927 | subexpression of @var{op} has one of a given list of RTX codes. |
| 928 | |
| 929 | The first operand of this expression is a string constant containing a |
| 930 | comma-separated list of RTX code names (in lower case). These are the |
| 931 | codes for which the @code{MATCH_CODE} will be true. |
| 932 | |
| 933 | The second operand is a string constant which indicates what |
| 934 | subexpression of @var{op} to examine. If it is absent or the empty |
| 935 | string, @var{op} itself is examined. Otherwise, the string constant |
| 936 | must be a sequence of digits and/or lowercase letters. Each character |
| 937 | indicates a subexpression to extract from the current expression; for |
| 938 | the first character this is @var{op}, for the second and subsequent |
| 939 | characters it is the result of the previous character. A digit |
| 940 | @var{n} extracts @samp{@w{XEXP (@var{e}, @var{n})}}; a letter @var{l} |
| 941 | extracts @samp{@w{XVECEXP (@var{e}, 0, @var{n})}} where @var{n} is the |
| 942 | alphabetic ordinal of @var{l} (0 for `a', 1 for 'b', and so on). The |
| 943 | @code{MATCH_CODE} then examines the RTX code of the subexpression |
| 944 | extracted by the complete string. It is not possible to extract |
| 945 | components of an @code{rtvec} that is not at position 0 within its RTX |
| 946 | object. |
| 947 | |
| 948 | @item MATCH_TEST |
| 949 | This expression has one operand, a string constant containing a C |
| 950 | expression. The predicate's arguments, @var{op} and @var{mode}, are |
| 951 | available with those names in the C expression. The @code{MATCH_TEST} |
| 952 | evaluates to true if the C expression evaluates to a nonzero value. |
| 953 | @code{MATCH_TEST} expressions must not have side effects. |
| 954 | |
| 955 | @item AND |
| 956 | @itemx IOR |
| 957 | @itemx NOT |
| 958 | @itemx IF_THEN_ELSE |
| 959 | The basic @samp{MATCH_} expressions can be combined using these |
| 960 | logical operators, which have the semantics of the C operators |
| 961 | @samp{&&}, @samp{||}, @samp{!}, and @samp{@w{? :}} respectively. As |
| 962 | in Common Lisp, you may give an @code{AND} or @code{IOR} expression an |
| 963 | arbitrary number of arguments; this has exactly the same effect as |
| 964 | writing a chain of two-argument @code{AND} or @code{IOR} expressions. |
| 965 | @end table |
| 966 | |
| 967 | @item |
| 968 | An optional block of C code, which should execute |
| 969 | @samp{@w{return true}} if the predicate is found to match and |
| 970 | @samp{@w{return false}} if it does not. It must not have any side |
| 971 | effects. The predicate arguments, @var{op} and @var{mode}, are |
| 972 | available with those names. |
| 973 | |
| 974 | If a code block is present in a predicate definition, then the RTL |
| 975 | expression must evaluate to true @emph{and} the code block must |
| 976 | execute @samp{@w{return true}} for the predicate to allow the operand. |
| 977 | The RTL expression is evaluated first; do not re-check anything in the |
| 978 | code block that was checked in the RTL expression. |
| 979 | @end itemize |
| 980 | |
| 981 | The program @command{genrecog} scans @code{define_predicate} and |
| 982 | @code{define_special_predicate} expressions to determine which RTX |
| 983 | codes are possibly allowed. You should always make this explicit in |
| 984 | the RTL predicate expression, using @code{MATCH_OPERAND} and |
| 985 | @code{MATCH_CODE}. |
| 986 | |
| 987 | Here is an example of a simple predicate definition, from the IA64 |
| 988 | machine description: |
| 989 | |
| 990 | @smallexample |
| 991 | @group |
| 992 | ;; @r{True if @var{op} is a @code{SYMBOL_REF} which refers to the sdata section.} |
| 993 | (define_predicate "small_addr_symbolic_operand" |
| 994 | (and (match_code "symbol_ref") |
| 995 | (match_test "SYMBOL_REF_SMALL_ADDR_P (op)"))) |
| 996 | @end group |
| 997 | @end smallexample |
| 998 | |
| 999 | @noindent |
| 1000 | And here is another, showing the use of the C block. |
| 1001 | |
| 1002 | @smallexample |
| 1003 | @group |
| 1004 | ;; @r{True if @var{op} is a register operand that is (or could be) a GR reg.} |
| 1005 | (define_predicate "gr_register_operand" |
| 1006 | (match_operand 0 "register_operand") |
| 1007 | @{ |
| 1008 | unsigned int regno; |
| 1009 | if (GET_CODE (op) == SUBREG) |
| 1010 | op = SUBREG_REG (op); |
| 1011 | |
| 1012 | regno = REGNO (op); |
| 1013 | return (regno >= FIRST_PSEUDO_REGISTER || GENERAL_REGNO_P (regno)); |
| 1014 | @}) |
| 1015 | @end group |
| 1016 | @end smallexample |
| 1017 | |
| 1018 | Predicates written with @code{define_predicate} automatically include |
| 1019 | a test that @var{mode} is @code{VOIDmode}, or @var{op} has the same |
| 1020 | mode as @var{mode}, or @var{op} is a @code{CONST_INT} or |
| 1021 | @code{CONST_DOUBLE}. They do @emph{not} check specifically for |
| 1022 | integer @code{CONST_DOUBLE}, nor do they test that the value of either |
| 1023 | kind of constant fits in the requested mode. This is because |
| 1024 | target-specific predicates that take constants usually have to do more |
| 1025 | stringent value checks anyway. If you need the exact same treatment |
| 1026 | of @code{CONST_INT} or @code{CONST_DOUBLE} that the generic predicates |
| 1027 | provide, use a @code{MATCH_OPERAND} subexpression to call |
| 1028 | @code{const_int_operand}, @code{const_double_operand}, or |
| 1029 | @code{immediate_operand}. |
| 1030 | |
| 1031 | Predicates written with @code{define_special_predicate} do not get any |
| 1032 | automatic mode checks, and are treated as having special mode handling |
| 1033 | by @command{genrecog}. |
| 1034 | |
| 1035 | The program @command{genpreds} is responsible for generating code to |
| 1036 | test predicates. It also writes a header file containing function |
| 1037 | declarations for all machine-specific predicates. It is not necessary |
| 1038 | to declare these predicates in @file{@var{cpu}-protos.h}. |
| 1039 | @end ifset |
| 1040 | |
| 1041 | @c Most of this node appears by itself (in a different place) even |
| 1042 | @c when the INTERNALS flag is clear. Passages that require the internals |
| 1043 | @c manual's context are conditionalized to appear only in the internals manual. |
| 1044 | @ifset INTERNALS |
| 1045 | @node Constraints |
| 1046 | @section Operand Constraints |
| 1047 | @cindex operand constraints |
| 1048 | @cindex constraints |
| 1049 | |
| 1050 | Each @code{match_operand} in an instruction pattern can specify |
| 1051 | constraints for the operands allowed. The constraints allow you to |
| 1052 | fine-tune matching within the set of operands allowed by the |
| 1053 | predicate. |
| 1054 | |
| 1055 | @end ifset |
| 1056 | @ifclear INTERNALS |
| 1057 | @node Constraints |
| 1058 | @section Constraints for @code{asm} Operands |
| 1059 | @cindex operand constraints, @code{asm} |
| 1060 | @cindex constraints, @code{asm} |
| 1061 | @cindex @code{asm} constraints |
| 1062 | |
| 1063 | Here are specific details on what constraint letters you can use with |
| 1064 | @code{asm} operands. |
| 1065 | @end ifclear |
| 1066 | Constraints can say whether |
| 1067 | an operand may be in a register, and which kinds of register; whether the |
| 1068 | operand can be a memory reference, and which kinds of address; whether the |
| 1069 | operand may be an immediate constant, and which possible values it may |
| 1070 | have. Constraints can also require two operands to match. |
| 1071 | Side-effects aren't allowed in operands of inline @code{asm}, unless |
| 1072 | @samp{<} or @samp{>} constraints are used, because there is no guarantee |
| 1073 | that the side-effects will happen exactly once in an instruction that can update |
| 1074 | the addressing register. |
| 1075 | |
| 1076 | @ifset INTERNALS |
| 1077 | @menu |
| 1078 | * Simple Constraints:: Basic use of constraints. |
| 1079 | * Multi-Alternative:: When an insn has two alternative constraint-patterns. |
| 1080 | * Class Preferences:: Constraints guide which hard register to put things in. |
| 1081 | * Modifiers:: More precise control over effects of constraints. |
| 1082 | * Disable Insn Alternatives:: Disable insn alternatives using the @code{enabled} attribute. |
| 1083 | * Machine Constraints:: Existing constraints for some particular machines. |
| 1084 | * Define Constraints:: How to define machine-specific constraints. |
| 1085 | * C Constraint Interface:: How to test constraints from C code. |
| 1086 | @end menu |
| 1087 | @end ifset |
| 1088 | |
| 1089 | @ifclear INTERNALS |
| 1090 | @menu |
| 1091 | * Simple Constraints:: Basic use of constraints. |
| 1092 | * Multi-Alternative:: When an insn has two alternative constraint-patterns. |
| 1093 | * Modifiers:: More precise control over effects of constraints. |
| 1094 | * Machine Constraints:: Special constraints for some particular machines. |
| 1095 | @end menu |
| 1096 | @end ifclear |
| 1097 | |
| 1098 | @node Simple Constraints |
| 1099 | @subsection Simple Constraints |
| 1100 | @cindex simple constraints |
| 1101 | |
| 1102 | The simplest kind of constraint is a string full of letters, each of |
| 1103 | which describes one kind of operand that is permitted. Here are |
| 1104 | the letters that are allowed: |
| 1105 | |
| 1106 | @table @asis |
| 1107 | @item whitespace |
| 1108 | Whitespace characters are ignored and can be inserted at any position |
| 1109 | except the first. This enables each alternative for different operands to |
| 1110 | be visually aligned in the machine description even if they have different |
| 1111 | number of constraints and modifiers. |
| 1112 | |
| 1113 | @cindex @samp{m} in constraint |
| 1114 | @cindex memory references in constraints |
| 1115 | @item @samp{m} |
| 1116 | A memory operand is allowed, with any kind of address that the machine |
| 1117 | supports in general. |
| 1118 | Note that the letter used for the general memory constraint can be |
| 1119 | re-defined by a back end using the @code{TARGET_MEM_CONSTRAINT} macro. |
| 1120 | |
| 1121 | @cindex offsettable address |
| 1122 | @cindex @samp{o} in constraint |
| 1123 | @item @samp{o} |
| 1124 | A memory operand is allowed, but only if the address is |
| 1125 | @dfn{offsettable}. This means that adding a small integer (actually, |
| 1126 | the width in bytes of the operand, as determined by its machine mode) |
| 1127 | may be added to the address and the result is also a valid memory |
| 1128 | address. |
| 1129 | |
| 1130 | @cindex autoincrement/decrement addressing |
| 1131 | For example, an address which is constant is offsettable; so is an |
| 1132 | address that is the sum of a register and a constant (as long as a |
| 1133 | slightly larger constant is also within the range of address-offsets |
| 1134 | supported by the machine); but an autoincrement or autodecrement |
| 1135 | address is not offsettable. More complicated indirect/indexed |
| 1136 | addresses may or may not be offsettable depending on the other |
| 1137 | addressing modes that the machine supports. |
| 1138 | |
| 1139 | Note that in an output operand which can be matched by another |
| 1140 | operand, the constraint letter @samp{o} is valid only when accompanied |
| 1141 | by both @samp{<} (if the target machine has predecrement addressing) |
| 1142 | and @samp{>} (if the target machine has preincrement addressing). |
| 1143 | |
| 1144 | @cindex @samp{V} in constraint |
| 1145 | @item @samp{V} |
| 1146 | A memory operand that is not offsettable. In other words, anything that |
| 1147 | would fit the @samp{m} constraint but not the @samp{o} constraint. |
| 1148 | |
| 1149 | @cindex @samp{<} in constraint |
| 1150 | @item @samp{<} |
| 1151 | A memory operand with autodecrement addressing (either predecrement or |
| 1152 | postdecrement) is allowed. In inline @code{asm} this constraint is only |
| 1153 | allowed if the operand is used exactly once in an instruction that can |
| 1154 | handle the side-effects. Not using an operand with @samp{<} in constraint |
| 1155 | string in the inline @code{asm} pattern at all or using it in multiple |
| 1156 | instructions isn't valid, because the side-effects wouldn't be performed |
| 1157 | or would be performed more than once. Furthermore, on some targets |
| 1158 | the operand with @samp{<} in constraint string must be accompanied by |
| 1159 | special instruction suffixes like @code{%U0} instruction suffix on PowerPC |
| 1160 | or @code{%P0} on IA-64. |
| 1161 | |
| 1162 | @cindex @samp{>} in constraint |
| 1163 | @item @samp{>} |
| 1164 | A memory operand with autoincrement addressing (either preincrement or |
| 1165 | postincrement) is allowed. In inline @code{asm} the same restrictions |
| 1166 | as for @samp{<} apply. |
| 1167 | |
| 1168 | @cindex @samp{r} in constraint |
| 1169 | @cindex registers in constraints |
| 1170 | @item @samp{r} |
| 1171 | A register operand is allowed provided that it is in a general |
| 1172 | register. |
| 1173 | |
| 1174 | @cindex constants in constraints |
| 1175 | @cindex @samp{i} in constraint |
| 1176 | @item @samp{i} |
| 1177 | An immediate integer operand (one with constant value) is allowed. |
| 1178 | This includes symbolic constants whose values will be known only at |
| 1179 | assembly time or later. |
| 1180 | |
| 1181 | @cindex @samp{n} in constraint |
| 1182 | @item @samp{n} |
| 1183 | An immediate integer operand with a known numeric value is allowed. |
| 1184 | Many systems cannot support assembly-time constants for operands less |
| 1185 | than a word wide. Constraints for these operands should use @samp{n} |
| 1186 | rather than @samp{i}. |
| 1187 | |
| 1188 | @cindex @samp{I} in constraint |
| 1189 | @item @samp{I}, @samp{J}, @samp{K}, @dots{} @samp{P} |
| 1190 | Other letters in the range @samp{I} through @samp{P} may be defined in |
| 1191 | a machine-dependent fashion to permit immediate integer operands with |
| 1192 | explicit integer values in specified ranges. For example, on the |
| 1193 | 68000, @samp{I} is defined to stand for the range of values 1 to 8. |
| 1194 | This is the range permitted as a shift count in the shift |
| 1195 | instructions. |
| 1196 | |
| 1197 | @cindex @samp{E} in constraint |
| 1198 | @item @samp{E} |
| 1199 | An immediate floating operand (expression code @code{const_double}) is |
| 1200 | allowed, but only if the target floating point format is the same as |
| 1201 | that of the host machine (on which the compiler is running). |
| 1202 | |
| 1203 | @cindex @samp{F} in constraint |
| 1204 | @item @samp{F} |
| 1205 | An immediate floating operand (expression code @code{const_double} or |
| 1206 | @code{const_vector}) is allowed. |
| 1207 | |
| 1208 | @cindex @samp{G} in constraint |
| 1209 | @cindex @samp{H} in constraint |
| 1210 | @item @samp{G}, @samp{H} |
| 1211 | @samp{G} and @samp{H} may be defined in a machine-dependent fashion to |
| 1212 | permit immediate floating operands in particular ranges of values. |
| 1213 | |
| 1214 | @cindex @samp{s} in constraint |
| 1215 | @item @samp{s} |
| 1216 | An immediate integer operand whose value is not an explicit integer is |
| 1217 | allowed. |
| 1218 | |
| 1219 | This might appear strange; if an insn allows a constant operand with a |
| 1220 | value not known at compile time, it certainly must allow any known |
| 1221 | value. So why use @samp{s} instead of @samp{i}? Sometimes it allows |
| 1222 | better code to be generated. |
| 1223 | |
| 1224 | For example, on the 68000 in a fullword instruction it is possible to |
| 1225 | use an immediate operand; but if the immediate value is between @minus{}128 |
| 1226 | and 127, better code results from loading the value into a register and |
| 1227 | using the register. This is because the load into the register can be |
| 1228 | done with a @samp{moveq} instruction. We arrange for this to happen |
| 1229 | by defining the letter @samp{K} to mean ``any integer outside the |
| 1230 | range @minus{}128 to 127'', and then specifying @samp{Ks} in the operand |
| 1231 | constraints. |
| 1232 | |
| 1233 | @cindex @samp{g} in constraint |
| 1234 | @item @samp{g} |
| 1235 | Any register, memory or immediate integer operand is allowed, except for |
| 1236 | registers that are not general registers. |
| 1237 | |
| 1238 | @cindex @samp{X} in constraint |
| 1239 | @item @samp{X} |
| 1240 | @ifset INTERNALS |
| 1241 | Any operand whatsoever is allowed, even if it does not satisfy |
| 1242 | @code{general_operand}. This is normally used in the constraint of |
| 1243 | a @code{match_scratch} when certain alternatives will not actually |
| 1244 | require a scratch register. |
| 1245 | @end ifset |
| 1246 | @ifclear INTERNALS |
| 1247 | Any operand whatsoever is allowed. |
| 1248 | @end ifclear |
| 1249 | |
| 1250 | @cindex @samp{0} in constraint |
| 1251 | @cindex digits in constraint |
| 1252 | @item @samp{0}, @samp{1}, @samp{2}, @dots{} @samp{9} |
| 1253 | An operand that matches the specified operand number is allowed. If a |
| 1254 | digit is used together with letters within the same alternative, the |
| 1255 | digit should come last. |
| 1256 | |
| 1257 | This number is allowed to be more than a single digit. If multiple |
| 1258 | digits are encountered consecutively, they are interpreted as a single |
| 1259 | decimal integer. There is scant chance for ambiguity, since to-date |
| 1260 | it has never been desirable that @samp{10} be interpreted as matching |
| 1261 | either operand 1 @emph{or} operand 0. Should this be desired, one |
| 1262 | can use multiple alternatives instead. |
| 1263 | |
| 1264 | @cindex matching constraint |
| 1265 | @cindex constraint, matching |
| 1266 | This is called a @dfn{matching constraint} and what it really means is |
| 1267 | that the assembler has only a single operand that fills two roles |
| 1268 | @ifset INTERNALS |
| 1269 | considered separate in the RTL insn. For example, an add insn has two |
| 1270 | input operands and one output operand in the RTL, but on most CISC |
| 1271 | @end ifset |
| 1272 | @ifclear INTERNALS |
| 1273 | which @code{asm} distinguishes. For example, an add instruction uses |
| 1274 | two input operands and an output operand, but on most CISC |
| 1275 | @end ifclear |
| 1276 | machines an add instruction really has only two operands, one of them an |
| 1277 | input-output operand: |
| 1278 | |
| 1279 | @smallexample |
| 1280 | addl #35,r12 |
| 1281 | @end smallexample |
| 1282 | |
| 1283 | Matching constraints are used in these circumstances. |
| 1284 | More precisely, the two operands that match must include one input-only |
| 1285 | operand and one output-only operand. Moreover, the digit must be a |
| 1286 | smaller number than the number of the operand that uses it in the |
| 1287 | constraint. |
| 1288 | |
| 1289 | @ifset INTERNALS |
| 1290 | For operands to match in a particular case usually means that they |
| 1291 | are identical-looking RTL expressions. But in a few special cases |
| 1292 | specific kinds of dissimilarity are allowed. For example, @code{*x} |
| 1293 | as an input operand will match @code{*x++} as an output operand. |
| 1294 | For proper results in such cases, the output template should always |
| 1295 | use the output-operand's number when printing the operand. |
| 1296 | @end ifset |
| 1297 | |
| 1298 | @cindex load address instruction |
| 1299 | @cindex push address instruction |
| 1300 | @cindex address constraints |
| 1301 | @cindex @samp{p} in constraint |
| 1302 | @item @samp{p} |
| 1303 | An operand that is a valid memory address is allowed. This is |
| 1304 | for ``load address'' and ``push address'' instructions. |
| 1305 | |
| 1306 | @findex address_operand |
| 1307 | @samp{p} in the constraint must be accompanied by @code{address_operand} |
| 1308 | as the predicate in the @code{match_operand}. This predicate interprets |
| 1309 | the mode specified in the @code{match_operand} as the mode of the memory |
| 1310 | reference for which the address would be valid. |
| 1311 | |
| 1312 | @cindex other register constraints |
| 1313 | @cindex extensible constraints |
| 1314 | @item @var{other-letters} |
| 1315 | Other letters can be defined in machine-dependent fashion to stand for |
| 1316 | particular classes of registers or other arbitrary operand types. |
| 1317 | @samp{d}, @samp{a} and @samp{f} are defined on the 68000/68020 to stand |
| 1318 | for data, address and floating point registers. |
| 1319 | @end table |
| 1320 | |
| 1321 | @ifset INTERNALS |
| 1322 | In order to have valid assembler code, each operand must satisfy |
| 1323 | its constraint. But a failure to do so does not prevent the pattern |
| 1324 | from applying to an insn. Instead, it directs the compiler to modify |
| 1325 | the code so that the constraint will be satisfied. Usually this is |
| 1326 | done by copying an operand into a register. |
| 1327 | |
| 1328 | Contrast, therefore, the two instruction patterns that follow: |
| 1329 | |
| 1330 | @smallexample |
| 1331 | (define_insn "" |
| 1332 | [(set (match_operand:SI 0 "general_operand" "=r") |
| 1333 | (plus:SI (match_dup 0) |
| 1334 | (match_operand:SI 1 "general_operand" "r")))] |
| 1335 | "" |
| 1336 | "@dots{}") |
| 1337 | @end smallexample |
| 1338 | |
| 1339 | @noindent |
| 1340 | which has two operands, one of which must appear in two places, and |
| 1341 | |
| 1342 | @smallexample |
| 1343 | (define_insn "" |
| 1344 | [(set (match_operand:SI 0 "general_operand" "=r") |
| 1345 | (plus:SI (match_operand:SI 1 "general_operand" "0") |
| 1346 | (match_operand:SI 2 "general_operand" "r")))] |
| 1347 | "" |
| 1348 | "@dots{}") |
| 1349 | @end smallexample |
| 1350 | |
| 1351 | @noindent |
| 1352 | which has three operands, two of which are required by a constraint to be |
| 1353 | identical. If we are considering an insn of the form |
| 1354 | |
| 1355 | @smallexample |
| 1356 | (insn @var{n} @var{prev} @var{next} |
| 1357 | (set (reg:SI 3) |
| 1358 | (plus:SI (reg:SI 6) (reg:SI 109))) |
| 1359 | @dots{}) |
| 1360 | @end smallexample |
| 1361 | |
| 1362 | @noindent |
| 1363 | the first pattern would not apply at all, because this insn does not |
| 1364 | contain two identical subexpressions in the right place. The pattern would |
| 1365 | say, ``That does not look like an add instruction; try other patterns''. |
| 1366 | The second pattern would say, ``Yes, that's an add instruction, but there |
| 1367 | is something wrong with it''. It would direct the reload pass of the |
| 1368 | compiler to generate additional insns to make the constraint true. The |
| 1369 | results might look like this: |
| 1370 | |
| 1371 | @smallexample |
| 1372 | (insn @var{n2} @var{prev} @var{n} |
| 1373 | (set (reg:SI 3) (reg:SI 6)) |
| 1374 | @dots{}) |
| 1375 | |
| 1376 | (insn @var{n} @var{n2} @var{next} |
| 1377 | (set (reg:SI 3) |
| 1378 | (plus:SI (reg:SI 3) (reg:SI 109))) |
| 1379 | @dots{}) |
| 1380 | @end smallexample |
| 1381 | |
| 1382 | It is up to you to make sure that each operand, in each pattern, has |
| 1383 | constraints that can handle any RTL expression that could be present for |
| 1384 | that operand. (When multiple alternatives are in use, each pattern must, |
| 1385 | for each possible combination of operand expressions, have at least one |
| 1386 | alternative which can handle that combination of operands.) The |
| 1387 | constraints don't need to @emph{allow} any possible operand---when this is |
| 1388 | the case, they do not constrain---but they must at least point the way to |
| 1389 | reloading any possible operand so that it will fit. |
| 1390 | |
| 1391 | @itemize @bullet |
| 1392 | @item |
| 1393 | If the constraint accepts whatever operands the predicate permits, |
| 1394 | there is no problem: reloading is never necessary for this operand. |
| 1395 | |
| 1396 | For example, an operand whose constraints permit everything except |
| 1397 | registers is safe provided its predicate rejects registers. |
| 1398 | |
| 1399 | An operand whose predicate accepts only constant values is safe |
| 1400 | provided its constraints include the letter @samp{i}. If any possible |
| 1401 | constant value is accepted, then nothing less than @samp{i} will do; |
| 1402 | if the predicate is more selective, then the constraints may also be |
| 1403 | more selective. |
| 1404 | |
| 1405 | @item |
| 1406 | Any operand expression can be reloaded by copying it into a register. |
| 1407 | So if an operand's constraints allow some kind of register, it is |
| 1408 | certain to be safe. It need not permit all classes of registers; the |
| 1409 | compiler knows how to copy a register into another register of the |
| 1410 | proper class in order to make an instruction valid. |
| 1411 | |
| 1412 | @cindex nonoffsettable memory reference |
| 1413 | @cindex memory reference, nonoffsettable |
| 1414 | @item |
| 1415 | A nonoffsettable memory reference can be reloaded by copying the |
| 1416 | address into a register. So if the constraint uses the letter |
| 1417 | @samp{o}, all memory references are taken care of. |
| 1418 | |
| 1419 | @item |
| 1420 | A constant operand can be reloaded by allocating space in memory to |
| 1421 | hold it as preinitialized data. Then the memory reference can be used |
| 1422 | in place of the constant. So if the constraint uses the letters |
| 1423 | @samp{o} or @samp{m}, constant operands are not a problem. |
| 1424 | |
| 1425 | @item |
| 1426 | If the constraint permits a constant and a pseudo register used in an insn |
| 1427 | was not allocated to a hard register and is equivalent to a constant, |
| 1428 | the register will be replaced with the constant. If the predicate does |
| 1429 | not permit a constant and the insn is re-recognized for some reason, the |
| 1430 | compiler will crash. Thus the predicate must always recognize any |
| 1431 | objects allowed by the constraint. |
| 1432 | @end itemize |
| 1433 | |
| 1434 | If the operand's predicate can recognize registers, but the constraint does |
| 1435 | not permit them, it can make the compiler crash. When this operand happens |
| 1436 | to be a register, the reload pass will be stymied, because it does not know |
| 1437 | how to copy a register temporarily into memory. |
| 1438 | |
| 1439 | If the predicate accepts a unary operator, the constraint applies to the |
| 1440 | operand. For example, the MIPS processor at ISA level 3 supports an |
| 1441 | instruction which adds two registers in @code{SImode} to produce a |
| 1442 | @code{DImode} result, but only if the registers are correctly sign |
| 1443 | extended. This predicate for the input operands accepts a |
| 1444 | @code{sign_extend} of an @code{SImode} register. Write the constraint |
| 1445 | to indicate the type of register that is required for the operand of the |
| 1446 | @code{sign_extend}. |
| 1447 | @end ifset |
| 1448 | |
| 1449 | @node Multi-Alternative |
| 1450 | @subsection Multiple Alternative Constraints |
| 1451 | @cindex multiple alternative constraints |
| 1452 | |
| 1453 | Sometimes a single instruction has multiple alternative sets of possible |
| 1454 | operands. For example, on the 68000, a logical-or instruction can combine |
| 1455 | register or an immediate value into memory, or it can combine any kind of |
| 1456 | operand into a register; but it cannot combine one memory location into |
| 1457 | another. |
| 1458 | |
| 1459 | These constraints are represented as multiple alternatives. An alternative |
| 1460 | can be described by a series of letters for each operand. The overall |
| 1461 | constraint for an operand is made from the letters for this operand |
| 1462 | from the first alternative, a comma, the letters for this operand from |
| 1463 | the second alternative, a comma, and so on until the last alternative. |
| 1464 | @ifset INTERNALS |
| 1465 | Here is how it is done for fullword logical-or on the 68000: |
| 1466 | |
| 1467 | @smallexample |
| 1468 | (define_insn "iorsi3" |
| 1469 | [(set (match_operand:SI 0 "general_operand" "=m,d") |
| 1470 | (ior:SI (match_operand:SI 1 "general_operand" "%0,0") |
| 1471 | (match_operand:SI 2 "general_operand" "dKs,dmKs")))] |
| 1472 | @dots{}) |
| 1473 | @end smallexample |
| 1474 | |
| 1475 | The first alternative has @samp{m} (memory) for operand 0, @samp{0} for |
| 1476 | operand 1 (meaning it must match operand 0), and @samp{dKs} for operand |
| 1477 | 2. The second alternative has @samp{d} (data register) for operand 0, |
| 1478 | @samp{0} for operand 1, and @samp{dmKs} for operand 2. The @samp{=} and |
| 1479 | @samp{%} in the constraints apply to all the alternatives; their |
| 1480 | meaning is explained in the next section (@pxref{Class Preferences}). |
| 1481 | @end ifset |
| 1482 | |
| 1483 | @c FIXME Is this ? and ! stuff of use in asm()? If not, hide unless INTERNAL |
| 1484 | If all the operands fit any one alternative, the instruction is valid. |
| 1485 | Otherwise, for each alternative, the compiler counts how many instructions |
| 1486 | must be added to copy the operands so that that alternative applies. |
| 1487 | The alternative requiring the least copying is chosen. If two alternatives |
| 1488 | need the same amount of copying, the one that comes first is chosen. |
| 1489 | These choices can be altered with the @samp{?} and @samp{!} characters: |
| 1490 | |
| 1491 | @table @code |
| 1492 | @cindex @samp{?} in constraint |
| 1493 | @cindex question mark |
| 1494 | @item ? |
| 1495 | Disparage slightly the alternative that the @samp{?} appears in, |
| 1496 | as a choice when no alternative applies exactly. The compiler regards |
| 1497 | this alternative as one unit more costly for each @samp{?} that appears |
| 1498 | in it. |
| 1499 | |
| 1500 | @cindex @samp{!} in constraint |
| 1501 | @cindex exclamation point |
| 1502 | @item ! |
| 1503 | Disparage severely the alternative that the @samp{!} appears in. |
| 1504 | This alternative can still be used if it fits without reloading, |
| 1505 | but if reloading is needed, some other alternative will be used. |
| 1506 | @end table |
| 1507 | |
| 1508 | @ifset INTERNALS |
| 1509 | When an insn pattern has multiple alternatives in its constraints, often |
| 1510 | the appearance of the assembler code is determined mostly by which |
| 1511 | alternative was matched. When this is so, the C code for writing the |
| 1512 | assembler code can use the variable @code{which_alternative}, which is |
| 1513 | the ordinal number of the alternative that was actually satisfied (0 for |
| 1514 | the first, 1 for the second alternative, etc.). @xref{Output Statement}. |
| 1515 | @end ifset |
| 1516 | |
| 1517 | @ifset INTERNALS |
| 1518 | @node Class Preferences |
| 1519 | @subsection Register Class Preferences |
| 1520 | @cindex class preference constraints |
| 1521 | @cindex register class preference constraints |
| 1522 | |
| 1523 | @cindex voting between constraint alternatives |
| 1524 | The operand constraints have another function: they enable the compiler |
| 1525 | to decide which kind of hardware register a pseudo register is best |
| 1526 | allocated to. The compiler examines the constraints that apply to the |
| 1527 | insns that use the pseudo register, looking for the machine-dependent |
| 1528 | letters such as @samp{d} and @samp{a} that specify classes of registers. |
| 1529 | The pseudo register is put in whichever class gets the most ``votes''. |
| 1530 | The constraint letters @samp{g} and @samp{r} also vote: they vote in |
| 1531 | favor of a general register. The machine description says which registers |
| 1532 | are considered general. |
| 1533 | |
| 1534 | Of course, on some machines all registers are equivalent, and no register |
| 1535 | classes are defined. Then none of this complexity is relevant. |
| 1536 | @end ifset |
| 1537 | |
| 1538 | @node Modifiers |
| 1539 | @subsection Constraint Modifier Characters |
| 1540 | @cindex modifiers in constraints |
| 1541 | @cindex constraint modifier characters |
| 1542 | |
| 1543 | @c prevent bad page break with this line |
| 1544 | Here are constraint modifier characters. |
| 1545 | |
| 1546 | @table @samp |
| 1547 | @cindex @samp{=} in constraint |
| 1548 | @item = |
| 1549 | Means that this operand is write-only for this instruction: the previous |
| 1550 | value is discarded and replaced by output data. |
| 1551 | |
| 1552 | @cindex @samp{+} in constraint |
| 1553 | @item + |
| 1554 | Means that this operand is both read and written by the instruction. |
| 1555 | |
| 1556 | When the compiler fixes up the operands to satisfy the constraints, |
| 1557 | it needs to know which operands are inputs to the instruction and |
| 1558 | which are outputs from it. @samp{=} identifies an output; @samp{+} |
| 1559 | identifies an operand that is both input and output; all other operands |
| 1560 | are assumed to be input only. |
| 1561 | |
| 1562 | If you specify @samp{=} or @samp{+} in a constraint, you put it in the |
| 1563 | first character of the constraint string. |
| 1564 | |
| 1565 | @cindex @samp{&} in constraint |
| 1566 | @cindex earlyclobber operand |
| 1567 | @item & |
| 1568 | Means (in a particular alternative) that this operand is an |
| 1569 | @dfn{earlyclobber} operand, which is modified before the instruction is |
| 1570 | finished using the input operands. Therefore, this operand may not lie |
| 1571 | in a register that is used as an input operand or as part of any memory |
| 1572 | address. |
| 1573 | |
| 1574 | @samp{&} applies only to the alternative in which it is written. In |
| 1575 | constraints with multiple alternatives, sometimes one alternative |
| 1576 | requires @samp{&} while others do not. See, for example, the |
| 1577 | @samp{movdf} insn of the 68000. |
| 1578 | |
| 1579 | An input operand can be tied to an earlyclobber operand if its only |
| 1580 | use as an input occurs before the early result is written. Adding |
| 1581 | alternatives of this form often allows GCC to produce better code |
| 1582 | when only some of the inputs can be affected by the earlyclobber. |
| 1583 | See, for example, the @samp{mulsi3} insn of the ARM@. |
| 1584 | |
| 1585 | @samp{&} does not obviate the need to write @samp{=}. |
| 1586 | |
| 1587 | @cindex @samp{%} in constraint |
| 1588 | @item % |
| 1589 | Declares the instruction to be commutative for this operand and the |
| 1590 | following operand. This means that the compiler may interchange the |
| 1591 | two operands if that is the cheapest way to make all operands fit the |
| 1592 | constraints. |
| 1593 | @ifset INTERNALS |
| 1594 | This is often used in patterns for addition instructions |
| 1595 | that really have only two operands: the result must go in one of the |
| 1596 | arguments. Here for example, is how the 68000 halfword-add |
| 1597 | instruction is defined: |
| 1598 | |
| 1599 | @smallexample |
| 1600 | (define_insn "addhi3" |
| 1601 | [(set (match_operand:HI 0 "general_operand" "=m,r") |
| 1602 | (plus:HI (match_operand:HI 1 "general_operand" "%0,0") |
| 1603 | (match_operand:HI 2 "general_operand" "di,g")))] |
| 1604 | @dots{}) |
| 1605 | @end smallexample |
| 1606 | @end ifset |
| 1607 | GCC can only handle one commutative pair in an asm; if you use more, |
| 1608 | the compiler may fail. Note that you need not use the modifier if |
| 1609 | the two alternatives are strictly identical; this would only waste |
| 1610 | time in the reload pass. The modifier is not operational after |
| 1611 | register allocation, so the result of @code{define_peephole2} |
| 1612 | and @code{define_split}s performed after reload cannot rely on |
| 1613 | @samp{%} to make the intended insn match. |
| 1614 | |
| 1615 | @cindex @samp{#} in constraint |
| 1616 | @item # |
| 1617 | Says that all following characters, up to the next comma, are to be |
| 1618 | ignored as a constraint. They are significant only for choosing |
| 1619 | register preferences. |
| 1620 | |
| 1621 | @cindex @samp{*} in constraint |
| 1622 | @item * |
| 1623 | Says that the following character should be ignored when choosing |
| 1624 | register preferences. @samp{*} has no effect on the meaning of the |
| 1625 | constraint as a constraint, and no effect on reloading. |
| 1626 | |
| 1627 | @ifset INTERNALS |
| 1628 | Here is an example: the 68000 has an instruction to sign-extend a |
| 1629 | halfword in a data register, and can also sign-extend a value by |
| 1630 | copying it into an address register. While either kind of register is |
| 1631 | acceptable, the constraints on an address-register destination are |
| 1632 | less strict, so it is best if register allocation makes an address |
| 1633 | register its goal. Therefore, @samp{*} is used so that the @samp{d} |
| 1634 | constraint letter (for data register) is ignored when computing |
| 1635 | register preferences. |
| 1636 | |
| 1637 | @smallexample |
| 1638 | (define_insn "extendhisi2" |
| 1639 | [(set (match_operand:SI 0 "general_operand" "=*d,a") |
| 1640 | (sign_extend:SI |
| 1641 | (match_operand:HI 1 "general_operand" "0,g")))] |
| 1642 | @dots{}) |
| 1643 | @end smallexample |
| 1644 | @end ifset |
| 1645 | @end table |
| 1646 | |
| 1647 | @node Machine Constraints |
| 1648 | @subsection Constraints for Particular Machines |
| 1649 | @cindex machine specific constraints |
| 1650 | @cindex constraints, machine specific |
| 1651 | |
| 1652 | Whenever possible, you should use the general-purpose constraint letters |
| 1653 | in @code{asm} arguments, since they will convey meaning more readily to |
| 1654 | people reading your code. Failing that, use the constraint letters |
| 1655 | that usually have very similar meanings across architectures. The most |
| 1656 | commonly used constraints are @samp{m} and @samp{r} (for memory and |
| 1657 | general-purpose registers respectively; @pxref{Simple Constraints}), and |
| 1658 | @samp{I}, usually the letter indicating the most common |
| 1659 | immediate-constant format. |
| 1660 | |
| 1661 | Each architecture defines additional constraints. These constraints |
| 1662 | are used by the compiler itself for instruction generation, as well as |
| 1663 | for @code{asm} statements; therefore, some of the constraints are not |
| 1664 | particularly useful for @code{asm}. Here is a summary of some of the |
| 1665 | machine-dependent constraints available on some particular machines; |
| 1666 | it includes both constraints that are useful for @code{asm} and |
| 1667 | constraints that aren't. The compiler source file mentioned in the |
| 1668 | table heading for each architecture is the definitive reference for |
| 1669 | the meanings of that architecture's constraints. |
| 1670 | |
| 1671 | @table @emph |
| 1672 | @item AArch64 family---@file{config/aarch64/constraints.md} |
| 1673 | @table @code |
| 1674 | @item k |
| 1675 | The stack pointer register (@code{SP}) |
| 1676 | |
| 1677 | @item w |
| 1678 | Floating point or SIMD vector register |
| 1679 | |
| 1680 | @item I |
| 1681 | Integer constant that is valid as an immediate operand in an @code{ADD} |
| 1682 | instruction |
| 1683 | |
| 1684 | @item J |
| 1685 | Integer constant that is valid as an immediate operand in a @code{SUB} |
| 1686 | instruction (once negated) |
| 1687 | |
| 1688 | @item K |
| 1689 | Integer constant that can be used with a 32-bit logical instruction |
| 1690 | |
| 1691 | @item L |
| 1692 | Integer constant that can be used with a 64-bit logical instruction |
| 1693 | |
| 1694 | @item M |
| 1695 | Integer constant that is valid as an immediate operand in a 32-bit @code{MOV} |
| 1696 | pseudo instruction. The @code{MOV} may be assembled to one of several different |
| 1697 | machine instructions depending on the value |
| 1698 | |
| 1699 | @item N |
| 1700 | Integer constant that is valid as an immediate operand in a 64-bit @code{MOV} |
| 1701 | pseudo instruction |
| 1702 | |
| 1703 | @item S |
| 1704 | An absolute symbolic address or a label reference |
| 1705 | |
| 1706 | @item Y |
| 1707 | Floating point constant zero |
| 1708 | |
| 1709 | @item Z |
| 1710 | Integer constant zero |
| 1711 | |
| 1712 | @item Usa |
| 1713 | An absolute symbolic address |
| 1714 | |
| 1715 | @item Ush |
| 1716 | The high part (bits 12 and upwards) of the pc-relative address of a symbol |
| 1717 | within 4GB of the instruction |
| 1718 | |
| 1719 | @item Q |
| 1720 | A memory address which uses a single base register with no offset |
| 1721 | |
| 1722 | @item Ump |
| 1723 | A memory address suitable for a load/store pair instruction in SI, DI, SF and |
| 1724 | DF modes |
| 1725 | |
| 1726 | @item Utf |
| 1727 | A memory address suitable for a load/store pair instruction in TF mode |
| 1728 | |
| 1729 | @end table |
| 1730 | |
| 1731 | |
| 1732 | @item ARM family---@file{config/arm/constraints.md} |
| 1733 | @table @code |
| 1734 | @item w |
| 1735 | VFP floating-point register |
| 1736 | |
| 1737 | @item G |
| 1738 | The floating-point constant 0.0 |
| 1739 | |
| 1740 | @item I |
| 1741 | Integer that is valid as an immediate operand in a data processing |
| 1742 | instruction. That is, an integer in the range 0 to 255 rotated by a |
| 1743 | multiple of 2 |
| 1744 | |
| 1745 | @item J |
| 1746 | Integer in the range @minus{}4095 to 4095 |
| 1747 | |
| 1748 | @item K |
| 1749 | Integer that satisfies constraint @samp{I} when inverted (ones complement) |
| 1750 | |
| 1751 | @item L |
| 1752 | Integer that satisfies constraint @samp{I} when negated (twos complement) |
| 1753 | |
| 1754 | @item M |
| 1755 | Integer in the range 0 to 32 |
| 1756 | |
| 1757 | @item Q |
| 1758 | A memory reference where the exact address is in a single register |
| 1759 | (`@samp{m}' is preferable for @code{asm} statements) |
| 1760 | |
| 1761 | @item R |
| 1762 | An item in the constant pool |
| 1763 | |
| 1764 | @item S |
| 1765 | A symbol in the text segment of the current file |
| 1766 | |
| 1767 | @item Uv |
| 1768 | A memory reference suitable for VFP load/store insns (reg+constant offset) |
| 1769 | |
| 1770 | @item Uy |
| 1771 | A memory reference suitable for iWMMXt load/store instructions. |
| 1772 | |
| 1773 | @item Uq |
| 1774 | A memory reference suitable for the ARMv4 ldrsb instruction. |
| 1775 | @end table |
| 1776 | |
| 1777 | @item AVR family---@file{config/avr/constraints.md} |
| 1778 | @table @code |
| 1779 | @item l |
| 1780 | Registers from r0 to r15 |
| 1781 | |
| 1782 | @item a |
| 1783 | Registers from r16 to r23 |
| 1784 | |
| 1785 | @item d |
| 1786 | Registers from r16 to r31 |
| 1787 | |
| 1788 | @item w |
| 1789 | Registers from r24 to r31. These registers can be used in @samp{adiw} command |
| 1790 | |
| 1791 | @item e |
| 1792 | Pointer register (r26--r31) |
| 1793 | |
| 1794 | @item b |
| 1795 | Base pointer register (r28--r31) |
| 1796 | |
| 1797 | @item q |
| 1798 | Stack pointer register (SPH:SPL) |
| 1799 | |
| 1800 | @item t |
| 1801 | Temporary register r0 |
| 1802 | |
| 1803 | @item x |
| 1804 | Register pair X (r27:r26) |
| 1805 | |
| 1806 | @item y |
| 1807 | Register pair Y (r29:r28) |
| 1808 | |
| 1809 | @item z |
| 1810 | Register pair Z (r31:r30) |
| 1811 | |
| 1812 | @item I |
| 1813 | Constant greater than @minus{}1, less than 64 |
| 1814 | |
| 1815 | @item J |
| 1816 | Constant greater than @minus{}64, less than 1 |
| 1817 | |
| 1818 | @item K |
| 1819 | Constant integer 2 |
| 1820 | |
| 1821 | @item L |
| 1822 | Constant integer 0 |
| 1823 | |
| 1824 | @item M |
| 1825 | Constant that fits in 8 bits |
| 1826 | |
| 1827 | @item N |
| 1828 | Constant integer @minus{}1 |
| 1829 | |
| 1830 | @item O |
| 1831 | Constant integer 8, 16, or 24 |
| 1832 | |
| 1833 | @item P |
| 1834 | Constant integer 1 |
| 1835 | |
| 1836 | @item G |
| 1837 | A floating point constant 0.0 |
| 1838 | |
| 1839 | @item Q |
| 1840 | A memory address based on Y or Z pointer with displacement. |
| 1841 | @end table |
| 1842 | |
| 1843 | @item Epiphany---@file{config/epiphany/constraints.md} |
| 1844 | @table @code |
| 1845 | @item U16 |
| 1846 | An unsigned 16-bit constant. |
| 1847 | |
| 1848 | @item K |
| 1849 | An unsigned 5-bit constant. |
| 1850 | |
| 1851 | @item L |
| 1852 | A signed 11-bit constant. |
| 1853 | |
| 1854 | @item Cm1 |
| 1855 | A signed 11-bit constant added to @minus{}1. |
| 1856 | Can only match when the @option{-m1reg-@var{reg}} option is active. |
| 1857 | |
| 1858 | @item Cl1 |
| 1859 | Left-shift of @minus{}1, i.e., a bit mask with a block of leading ones, the rest |
| 1860 | being a block of trailing zeroes. |
| 1861 | Can only match when the @option{-m1reg-@var{reg}} option is active. |
| 1862 | |
| 1863 | @item Cr1 |
| 1864 | Right-shift of @minus{}1, i.e., a bit mask with a trailing block of ones, the |
| 1865 | rest being zeroes. Or to put it another way, one less than a power of two. |
| 1866 | Can only match when the @option{-m1reg-@var{reg}} option is active. |
| 1867 | |
| 1868 | @item Cal |
| 1869 | Constant for arithmetic/logical operations. |
| 1870 | This is like @code{i}, except that for position independent code, |
| 1871 | no symbols / expressions needing relocations are allowed. |
| 1872 | |
| 1873 | @item Csy |
| 1874 | Symbolic constant for call/jump instruction. |
| 1875 | |
| 1876 | @item Rcs |
| 1877 | The register class usable in short insns. This is a register class |
| 1878 | constraint, and can thus drive register allocation. |
| 1879 | This constraint won't match unless @option{-mprefer-short-insn-regs} is |
| 1880 | in effect. |
| 1881 | |
| 1882 | @item Rsc |
| 1883 | The the register class of registers that can be used to hold a |
| 1884 | sibcall call address. I.e., a caller-saved register. |
| 1885 | |
| 1886 | @item Rct |
| 1887 | Core control register class. |
| 1888 | |
| 1889 | @item Rgs |
| 1890 | The register group usable in short insns. |
| 1891 | This constraint does not use a register class, so that it only |
| 1892 | passively matches suitable registers, and doesn't drive register allocation. |
| 1893 | |
| 1894 | @ifset INTERNALS |
| 1895 | @item Car |
| 1896 | Constant suitable for the addsi3_r pattern. This is a valid offset |
| 1897 | For byte, halfword, or word addressing. |
| 1898 | @end ifset |
| 1899 | |
| 1900 | @item Rra |
| 1901 | Matches the return address if it can be replaced with the link register. |
| 1902 | |
| 1903 | @item Rcc |
| 1904 | Matches the integer condition code register. |
| 1905 | |
| 1906 | @item Sra |
| 1907 | Matches the return address if it is in a stack slot. |
| 1908 | |
| 1909 | @item Cfm |
| 1910 | Matches control register values to switch fp mode, which are encapsulated in |
| 1911 | @code{UNSPEC_FP_MODE}. |
| 1912 | @end table |
| 1913 | |
| 1914 | @item CR16 Architecture---@file{config/cr16/cr16.h} |
| 1915 | @table @code |
| 1916 | |
| 1917 | @item b |
| 1918 | Registers from r0 to r14 (registers without stack pointer) |
| 1919 | |
| 1920 | @item t |
| 1921 | Register from r0 to r11 (all 16-bit registers) |
| 1922 | |
| 1923 | @item p |
| 1924 | Register from r12 to r15 (all 32-bit registers) |
| 1925 | |
| 1926 | @item I |
| 1927 | Signed constant that fits in 4 bits |
| 1928 | |
| 1929 | @item J |
| 1930 | Signed constant that fits in 5 bits |
| 1931 | |
| 1932 | @item K |
| 1933 | Signed constant that fits in 6 bits |
| 1934 | |
| 1935 | @item L |
| 1936 | Unsigned constant that fits in 4 bits |
| 1937 | |
| 1938 | @item M |
| 1939 | Signed constant that fits in 32 bits |
| 1940 | |
| 1941 | @item N |
| 1942 | Check for 64 bits wide constants for add/sub instructions |
| 1943 | |
| 1944 | @item G |
| 1945 | Floating point constant that is legal for store immediate |
| 1946 | @end table |
| 1947 | |
| 1948 | @item Hewlett-Packard PA-RISC---@file{config/pa/pa.h} |
| 1949 | @table @code |
| 1950 | @item a |
| 1951 | General register 1 |
| 1952 | |
| 1953 | @item f |
| 1954 | Floating point register |
| 1955 | |
| 1956 | @item q |
| 1957 | Shift amount register |
| 1958 | |
| 1959 | @item x |
| 1960 | Floating point register (deprecated) |
| 1961 | |
| 1962 | @item y |
| 1963 | Upper floating point register (32-bit), floating point register (64-bit) |
| 1964 | |
| 1965 | @item Z |
| 1966 | Any register |
| 1967 | |
| 1968 | @item I |
| 1969 | Signed 11-bit integer constant |
| 1970 | |
| 1971 | @item J |
| 1972 | Signed 14-bit integer constant |
| 1973 | |
| 1974 | @item K |
| 1975 | Integer constant that can be deposited with a @code{zdepi} instruction |
| 1976 | |
| 1977 | @item L |
| 1978 | Signed 5-bit integer constant |
| 1979 | |
| 1980 | @item M |
| 1981 | Integer constant 0 |
| 1982 | |
| 1983 | @item N |
| 1984 | Integer constant that can be loaded with a @code{ldil} instruction |
| 1985 | |
| 1986 | @item O |
| 1987 | Integer constant whose value plus one is a power of 2 |
| 1988 | |
| 1989 | @item P |
| 1990 | Integer constant that can be used for @code{and} operations in @code{depi} |
| 1991 | and @code{extru} instructions |
| 1992 | |
| 1993 | @item S |
| 1994 | Integer constant 31 |
| 1995 | |
| 1996 | @item U |
| 1997 | Integer constant 63 |
| 1998 | |
| 1999 | @item G |
| 2000 | Floating-point constant 0.0 |
| 2001 | |
| 2002 | @item A |
| 2003 | A @code{lo_sum} data-linkage-table memory operand |
| 2004 | |
| 2005 | @item Q |
| 2006 | A memory operand that can be used as the destination operand of an |
| 2007 | integer store instruction |
| 2008 | |
| 2009 | @item R |
| 2010 | A scaled or unscaled indexed memory operand |
| 2011 | |
| 2012 | @item T |
| 2013 | A memory operand for floating-point loads and stores |
| 2014 | |
| 2015 | @item W |
| 2016 | A register indirect memory operand |
| 2017 | @end table |
| 2018 | |
| 2019 | @item picoChip family---@file{picochip.h} |
| 2020 | @table @code |
| 2021 | @item k |
| 2022 | Stack register. |
| 2023 | |
| 2024 | @item f |
| 2025 | Pointer register. A register which can be used to access memory without |
| 2026 | supplying an offset. Any other register can be used to access memory, |
| 2027 | but will need a constant offset. In the case of the offset being zero, |
| 2028 | it is more efficient to use a pointer register, since this reduces code |
| 2029 | size. |
| 2030 | |
| 2031 | @item t |
| 2032 | A twin register. A register which may be paired with an adjacent |
| 2033 | register to create a 32-bit register. |
| 2034 | |
| 2035 | @item a |
| 2036 | Any absolute memory address (e.g., symbolic constant, symbolic |
| 2037 | constant + offset). |
| 2038 | |
| 2039 | @item I |
| 2040 | 4-bit signed integer. |
| 2041 | |
| 2042 | @item J |
| 2043 | 4-bit unsigned integer. |
| 2044 | |
| 2045 | @item K |
| 2046 | 8-bit signed integer. |
| 2047 | |
| 2048 | @item M |
| 2049 | Any constant whose absolute value is no greater than 4-bits. |
| 2050 | |
| 2051 | @item N |
| 2052 | 10-bit signed integer |
| 2053 | |
| 2054 | @item O |
| 2055 | 16-bit signed integer. |
| 2056 | |
| 2057 | @end table |
| 2058 | |
| 2059 | @item PowerPC and IBM RS6000---@file{config/rs6000/rs6000.h} |
| 2060 | @table @code |
| 2061 | @item b |
| 2062 | Address base register |
| 2063 | |
| 2064 | @item d |
| 2065 | Floating point register (containing 64-bit value) |
| 2066 | |
| 2067 | @item f |
| 2068 | Floating point register (containing 32-bit value) |
| 2069 | |
| 2070 | @item v |
| 2071 | Altivec vector register |
| 2072 | |
| 2073 | @item wd |
| 2074 | VSX vector register to hold vector double data |
| 2075 | |
| 2076 | @item wf |
| 2077 | VSX vector register to hold vector float data |
| 2078 | |
| 2079 | @item ws |
| 2080 | VSX vector register to hold scalar float data |
| 2081 | |
| 2082 | @item wa |
| 2083 | Any VSX register |
| 2084 | |
| 2085 | @item h |
| 2086 | @samp{MQ}, @samp{CTR}, or @samp{LINK} register |
| 2087 | |
| 2088 | @item q |
| 2089 | @samp{MQ} register |
| 2090 | |
| 2091 | @item c |
| 2092 | @samp{CTR} register |
| 2093 | |
| 2094 | @item l |
| 2095 | @samp{LINK} register |
| 2096 | |
| 2097 | @item x |
| 2098 | @samp{CR} register (condition register) number 0 |
| 2099 | |
| 2100 | @item y |
| 2101 | @samp{CR} register (condition register) |
| 2102 | |
| 2103 | @item z |
| 2104 | @samp{XER[CA]} carry bit (part of the XER register) |
| 2105 | |
| 2106 | @item I |
| 2107 | Signed 16-bit constant |
| 2108 | |
| 2109 | @item J |
| 2110 | Unsigned 16-bit constant shifted left 16 bits (use @samp{L} instead for |
| 2111 | @code{SImode} constants) |
| 2112 | |
| 2113 | @item K |
| 2114 | Unsigned 16-bit constant |
| 2115 | |
| 2116 | @item L |
| 2117 | Signed 16-bit constant shifted left 16 bits |
| 2118 | |
| 2119 | @item M |
| 2120 | Constant larger than 31 |
| 2121 | |
| 2122 | @item N |
| 2123 | Exact power of 2 |
| 2124 | |
| 2125 | @item O |
| 2126 | Zero |
| 2127 | |
| 2128 | @item P |
| 2129 | Constant whose negation is a signed 16-bit constant |
| 2130 | |
| 2131 | @item G |
| 2132 | Floating point constant that can be loaded into a register with one |
| 2133 | instruction per word |
| 2134 | |
| 2135 | @item H |
| 2136 | Integer/Floating point constant that can be loaded into a register using |
| 2137 | three instructions |
| 2138 | |
| 2139 | @item m |
| 2140 | Memory operand. |
| 2141 | Normally, @code{m} does not allow addresses that update the base register. |
| 2142 | If @samp{<} or @samp{>} constraint is also used, they are allowed and |
| 2143 | therefore on PowerPC targets in that case it is only safe |
| 2144 | to use @samp{m<>} in an @code{asm} statement if that @code{asm} statement |
| 2145 | accesses the operand exactly once. The @code{asm} statement must also |
| 2146 | use @samp{%U@var{<opno>}} as a placeholder for the ``update'' flag in the |
| 2147 | corresponding load or store instruction. For example: |
| 2148 | |
| 2149 | @smallexample |
| 2150 | asm ("st%U0 %1,%0" : "=m<>" (mem) : "r" (val)); |
| 2151 | @end smallexample |
| 2152 | |
| 2153 | is correct but: |
| 2154 | |
| 2155 | @smallexample |
| 2156 | asm ("st %1,%0" : "=m<>" (mem) : "r" (val)); |
| 2157 | @end smallexample |
| 2158 | |
| 2159 | is not. |
| 2160 | |
| 2161 | @item es |
| 2162 | A ``stable'' memory operand; that is, one which does not include any |
| 2163 | automodification of the base register. This used to be useful when |
| 2164 | @samp{m} allowed automodification of the base register, but as those are now only |
| 2165 | allowed when @samp{<} or @samp{>} is used, @samp{es} is basically the same |
| 2166 | as @samp{m} without @samp{<} and @samp{>}. |
| 2167 | |
| 2168 | @item Q |
| 2169 | Memory operand that is an offset from a register (it is usually better |
| 2170 | to use @samp{m} or @samp{es} in @code{asm} statements) |
| 2171 | |
| 2172 | @item Z |
| 2173 | Memory operand that is an indexed or indirect from a register (it is |
| 2174 | usually better to use @samp{m} or @samp{es} in @code{asm} statements) |
| 2175 | |
| 2176 | @item R |
| 2177 | AIX TOC entry |
| 2178 | |
| 2179 | @item a |
| 2180 | Address operand that is an indexed or indirect from a register (@samp{p} is |
| 2181 | preferable for @code{asm} statements) |
| 2182 | |
| 2183 | @item S |
| 2184 | Constant suitable as a 64-bit mask operand |
| 2185 | |
| 2186 | @item T |
| 2187 | Constant suitable as a 32-bit mask operand |
| 2188 | |
| 2189 | @item U |
| 2190 | System V Release 4 small data area reference |
| 2191 | |
| 2192 | @item t |
| 2193 | AND masks that can be performed by two rldic@{l, r@} instructions |
| 2194 | |
| 2195 | @item W |
| 2196 | Vector constant that does not require memory |
| 2197 | |
| 2198 | @item j |
| 2199 | Vector constant that is all zeros. |
| 2200 | |
| 2201 | @end table |
| 2202 | |
| 2203 | @item Intel 386---@file{config/i386/constraints.md} |
| 2204 | @table @code |
| 2205 | @item R |
| 2206 | Legacy register---the eight integer registers available on all |
| 2207 | i386 processors (@code{a}, @code{b}, @code{c}, @code{d}, |
| 2208 | @code{si}, @code{di}, @code{bp}, @code{sp}). |
| 2209 | |
| 2210 | @item q |
| 2211 | Any register accessible as @code{@var{r}l}. In 32-bit mode, @code{a}, |
| 2212 | @code{b}, @code{c}, and @code{d}; in 64-bit mode, any integer register. |
| 2213 | |
| 2214 | @item Q |
| 2215 | Any register accessible as @code{@var{r}h}: @code{a}, @code{b}, |
| 2216 | @code{c}, and @code{d}. |
| 2217 | |
| 2218 | @ifset INTERNALS |
| 2219 | @item l |
| 2220 | Any register that can be used as the index in a base+index memory |
| 2221 | access: that is, any general register except the stack pointer. |
| 2222 | @end ifset |
| 2223 | |
| 2224 | @item a |
| 2225 | The @code{a} register. |
| 2226 | |
| 2227 | @item b |
| 2228 | The @code{b} register. |
| 2229 | |
| 2230 | @item c |
| 2231 | The @code{c} register. |
| 2232 | |
| 2233 | @item d |
| 2234 | The @code{d} register. |
| 2235 | |
| 2236 | @item S |
| 2237 | The @code{si} register. |
| 2238 | |
| 2239 | @item D |
| 2240 | The @code{di} register. |
| 2241 | |
| 2242 | @item A |
| 2243 | The @code{a} and @code{d} registers. This class is used for instructions |
| 2244 | that return double word results in the @code{ax:dx} register pair. Single |
| 2245 | word values will be allocated either in @code{ax} or @code{dx}. |
| 2246 | For example on i386 the following implements @code{rdtsc}: |
| 2247 | |
| 2248 | @smallexample |
| 2249 | unsigned long long rdtsc (void) |
| 2250 | @{ |
| 2251 | unsigned long long tick; |
| 2252 | __asm__ __volatile__("rdtsc":"=A"(tick)); |
| 2253 | return tick; |
| 2254 | @} |
| 2255 | @end smallexample |
| 2256 | |
| 2257 | This is not correct on x86_64 as it would allocate tick in either @code{ax} |
| 2258 | or @code{dx}. You have to use the following variant instead: |
| 2259 | |
| 2260 | @smallexample |
| 2261 | unsigned long long rdtsc (void) |
| 2262 | @{ |
| 2263 | unsigned int tickl, tickh; |
| 2264 | __asm__ __volatile__("rdtsc":"=a"(tickl),"=d"(tickh)); |
| 2265 | return ((unsigned long long)tickh << 32)|tickl; |
| 2266 | @} |
| 2267 | @end smallexample |
| 2268 | |
| 2269 | |
| 2270 | @item f |
| 2271 | Any 80387 floating-point (stack) register. |
| 2272 | |
| 2273 | @item t |
| 2274 | Top of 80387 floating-point stack (@code{%st(0)}). |
| 2275 | |
| 2276 | @item u |
| 2277 | Second from top of 80387 floating-point stack (@code{%st(1)}). |
| 2278 | |
| 2279 | @item y |
| 2280 | Any MMX register. |
| 2281 | |
| 2282 | @item x |
| 2283 | Any SSE register. |
| 2284 | |
| 2285 | @item Yz |
| 2286 | First SSE register (@code{%xmm0}). |
| 2287 | |
| 2288 | @ifset INTERNALS |
| 2289 | @item Y2 |
| 2290 | Any SSE register, when SSE2 is enabled. |
| 2291 | |
| 2292 | @item Yi |
| 2293 | Any SSE register, when SSE2 and inter-unit moves are enabled. |
| 2294 | |
| 2295 | @item Ym |
| 2296 | Any MMX register, when inter-unit moves are enabled. |
| 2297 | @end ifset |
| 2298 | |
| 2299 | @item I |
| 2300 | Integer constant in the range 0 @dots{} 31, for 32-bit shifts. |
| 2301 | |
| 2302 | @item J |
| 2303 | Integer constant in the range 0 @dots{} 63, for 64-bit shifts. |
| 2304 | |
| 2305 | @item K |
| 2306 | Signed 8-bit integer constant. |
| 2307 | |
| 2308 | @item L |
| 2309 | @code{0xFF} or @code{0xFFFF}, for andsi as a zero-extending move. |
| 2310 | |
| 2311 | @item M |
| 2312 | 0, 1, 2, or 3 (shifts for the @code{lea} instruction). |
| 2313 | |
| 2314 | @item N |
| 2315 | Unsigned 8-bit integer constant (for @code{in} and @code{out} |
| 2316 | instructions). |
| 2317 | |
| 2318 | @ifset INTERNALS |
| 2319 | @item O |
| 2320 | Integer constant in the range 0 @dots{} 127, for 128-bit shifts. |
| 2321 | @end ifset |
| 2322 | |
| 2323 | @item G |
| 2324 | Standard 80387 floating point constant. |
| 2325 | |
| 2326 | @item C |
| 2327 | Standard SSE floating point constant. |
| 2328 | |
| 2329 | @item e |
| 2330 | 32-bit signed integer constant, or a symbolic reference known |
| 2331 | to fit that range (for immediate operands in sign-extending x86-64 |
| 2332 | instructions). |
| 2333 | |
| 2334 | @item Z |
| 2335 | 32-bit unsigned integer constant, or a symbolic reference known |
| 2336 | to fit that range (for immediate operands in zero-extending x86-64 |
| 2337 | instructions). |
| 2338 | |
| 2339 | @end table |
| 2340 | |
| 2341 | @item Intel IA-64---@file{config/ia64/ia64.h} |
| 2342 | @table @code |
| 2343 | @item a |
| 2344 | General register @code{r0} to @code{r3} for @code{addl} instruction |
| 2345 | |
| 2346 | @item b |
| 2347 | Branch register |
| 2348 | |
| 2349 | @item c |
| 2350 | Predicate register (@samp{c} as in ``conditional'') |
| 2351 | |
| 2352 | @item d |
| 2353 | Application register residing in M-unit |
| 2354 | |
| 2355 | @item e |
| 2356 | Application register residing in I-unit |
| 2357 | |
| 2358 | @item f |
| 2359 | Floating-point register |
| 2360 | |
| 2361 | @item m |
| 2362 | Memory operand. If used together with @samp{<} or @samp{>}, |
| 2363 | the operand can have postincrement and postdecrement which |
| 2364 | require printing with @samp{%Pn} on IA-64. |
| 2365 | |
| 2366 | @item G |
| 2367 | Floating-point constant 0.0 or 1.0 |
| 2368 | |
| 2369 | @item I |
| 2370 | 14-bit signed integer constant |
| 2371 | |
| 2372 | @item J |
| 2373 | 22-bit signed integer constant |
| 2374 | |
| 2375 | @item K |
| 2376 | 8-bit signed integer constant for logical instructions |
| 2377 | |
| 2378 | @item L |
| 2379 | 8-bit adjusted signed integer constant for compare pseudo-ops |
| 2380 | |
| 2381 | @item M |
| 2382 | 6-bit unsigned integer constant for shift counts |
| 2383 | |
| 2384 | @item N |
| 2385 | 9-bit signed integer constant for load and store postincrements |
| 2386 | |
| 2387 | @item O |
| 2388 | The constant zero |
| 2389 | |
| 2390 | @item P |
| 2391 | 0 or @minus{}1 for @code{dep} instruction |
| 2392 | |
| 2393 | @item Q |
| 2394 | Non-volatile memory for floating-point loads and stores |
| 2395 | |
| 2396 | @item R |
| 2397 | Integer constant in the range 1 to 4 for @code{shladd} instruction |
| 2398 | |
| 2399 | @item S |
| 2400 | Memory operand except postincrement and postdecrement. This is |
| 2401 | now roughly the same as @samp{m} when not used together with @samp{<} |
| 2402 | or @samp{>}. |
| 2403 | @end table |
| 2404 | |
| 2405 | @item FRV---@file{config/frv/frv.h} |
| 2406 | @table @code |
| 2407 | @item a |
| 2408 | Register in the class @code{ACC_REGS} (@code{acc0} to @code{acc7}). |
| 2409 | |
| 2410 | @item b |
| 2411 | Register in the class @code{EVEN_ACC_REGS} (@code{acc0} to @code{acc7}). |
| 2412 | |
| 2413 | @item c |
| 2414 | Register in the class @code{CC_REGS} (@code{fcc0} to @code{fcc3} and |
| 2415 | @code{icc0} to @code{icc3}). |
| 2416 | |
| 2417 | @item d |
| 2418 | Register in the class @code{GPR_REGS} (@code{gr0} to @code{gr63}). |
| 2419 | |
| 2420 | @item e |
| 2421 | Register in the class @code{EVEN_REGS} (@code{gr0} to @code{gr63}). |
| 2422 | Odd registers are excluded not in the class but through the use of a machine |
| 2423 | mode larger than 4 bytes. |
| 2424 | |
| 2425 | @item f |
| 2426 | Register in the class @code{FPR_REGS} (@code{fr0} to @code{fr63}). |
| 2427 | |
| 2428 | @item h |
| 2429 | Register in the class @code{FEVEN_REGS} (@code{fr0} to @code{fr63}). |
| 2430 | Odd registers are excluded not in the class but through the use of a machine |
| 2431 | mode larger than 4 bytes. |
| 2432 | |
| 2433 | @item l |
| 2434 | Register in the class @code{LR_REG} (the @code{lr} register). |
| 2435 | |
| 2436 | @item q |
| 2437 | Register in the class @code{QUAD_REGS} (@code{gr2} to @code{gr63}). |
| 2438 | Register numbers not divisible by 4 are excluded not in the class but through |
| 2439 | the use of a machine mode larger than 8 bytes. |
| 2440 | |
| 2441 | @item t |
| 2442 | Register in the class @code{ICC_REGS} (@code{icc0} to @code{icc3}). |
| 2443 | |
| 2444 | @item u |
| 2445 | Register in the class @code{FCC_REGS} (@code{fcc0} to @code{fcc3}). |
| 2446 | |
| 2447 | @item v |
| 2448 | Register in the class @code{ICR_REGS} (@code{cc4} to @code{cc7}). |
| 2449 | |
| 2450 | @item w |
| 2451 | Register in the class @code{FCR_REGS} (@code{cc0} to @code{cc3}). |
| 2452 | |
| 2453 | @item x |
| 2454 | Register in the class @code{QUAD_FPR_REGS} (@code{fr0} to @code{fr63}). |
| 2455 | Register numbers not divisible by 4 are excluded not in the class but through |
| 2456 | the use of a machine mode larger than 8 bytes. |
| 2457 | |
| 2458 | @item z |
| 2459 | Register in the class @code{SPR_REGS} (@code{lcr} and @code{lr}). |
| 2460 | |
| 2461 | @item A |
| 2462 | Register in the class @code{QUAD_ACC_REGS} (@code{acc0} to @code{acc7}). |
| 2463 | |
| 2464 | @item B |
| 2465 | Register in the class @code{ACCG_REGS} (@code{accg0} to @code{accg7}). |
| 2466 | |
| 2467 | @item C |
| 2468 | Register in the class @code{CR_REGS} (@code{cc0} to @code{cc7}). |
| 2469 | |
| 2470 | @item G |
| 2471 | Floating point constant zero |
| 2472 | |
| 2473 | @item I |
| 2474 | 6-bit signed integer constant |
| 2475 | |
| 2476 | @item J |
| 2477 | 10-bit signed integer constant |
| 2478 | |
| 2479 | @item L |
| 2480 | 16-bit signed integer constant |
| 2481 | |
| 2482 | @item M |
| 2483 | 16-bit unsigned integer constant |
| 2484 | |
| 2485 | @item N |
| 2486 | 12-bit signed integer constant that is negative---i.e.@: in the |
| 2487 | range of @minus{}2048 to @minus{}1 |
| 2488 | |
| 2489 | @item O |
| 2490 | Constant zero |
| 2491 | |
| 2492 | @item P |
| 2493 | 12-bit signed integer constant that is greater than zero---i.e.@: in the |
| 2494 | range of 1 to 2047. |
| 2495 | |
| 2496 | @end table |
| 2497 | |
| 2498 | @item Blackfin family---@file{config/bfin/constraints.md} |
| 2499 | @table @code |
| 2500 | @item a |
| 2501 | P register |
| 2502 | |
| 2503 | @item d |
| 2504 | D register |
| 2505 | |
| 2506 | @item z |
| 2507 | A call clobbered P register. |
| 2508 | |
| 2509 | @item q@var{n} |
| 2510 | A single register. If @var{n} is in the range 0 to 7, the corresponding D |
| 2511 | register. If it is @code{A}, then the register P0. |
| 2512 | |
| 2513 | @item D |
| 2514 | Even-numbered D register |
| 2515 | |
| 2516 | @item W |
| 2517 | Odd-numbered D register |
| 2518 | |
| 2519 | @item e |
| 2520 | Accumulator register. |
| 2521 | |
| 2522 | @item A |
| 2523 | Even-numbered accumulator register. |
| 2524 | |
| 2525 | @item B |
| 2526 | Odd-numbered accumulator register. |
| 2527 | |
| 2528 | @item b |
| 2529 | I register |
| 2530 | |
| 2531 | @item v |
| 2532 | B register |
| 2533 | |
| 2534 | @item f |
| 2535 | M register |
| 2536 | |
| 2537 | @item c |
| 2538 | Registers used for circular buffering, i.e. I, B, or L registers. |
| 2539 | |
| 2540 | @item C |
| 2541 | The CC register. |
| 2542 | |
| 2543 | @item t |
| 2544 | LT0 or LT1. |
| 2545 | |
| 2546 | @item k |
| 2547 | LC0 or LC1. |
| 2548 | |
| 2549 | @item u |
| 2550 | LB0 or LB1. |
| 2551 | |
| 2552 | @item x |
| 2553 | Any D, P, B, M, I or L register. |
| 2554 | |
| 2555 | @item y |
| 2556 | Additional registers typically used only in prologues and epilogues: RETS, |
| 2557 | RETN, RETI, RETX, RETE, ASTAT, SEQSTAT and USP. |
| 2558 | |
| 2559 | @item w |
| 2560 | Any register except accumulators or CC. |
| 2561 | |
| 2562 | @item Ksh |
| 2563 | Signed 16 bit integer (in the range @minus{}32768 to 32767) |
| 2564 | |
| 2565 | @item Kuh |
| 2566 | Unsigned 16 bit integer (in the range 0 to 65535) |
| 2567 | |
| 2568 | @item Ks7 |
| 2569 | Signed 7 bit integer (in the range @minus{}64 to 63) |
| 2570 | |
| 2571 | @item Ku7 |
| 2572 | Unsigned 7 bit integer (in the range 0 to 127) |
| 2573 | |
| 2574 | @item Ku5 |
| 2575 | Unsigned 5 bit integer (in the range 0 to 31) |
| 2576 | |
| 2577 | @item Ks4 |
| 2578 | Signed 4 bit integer (in the range @minus{}8 to 7) |
| 2579 | |
| 2580 | @item Ks3 |
| 2581 | Signed 3 bit integer (in the range @minus{}3 to 4) |
| 2582 | |
| 2583 | @item Ku3 |
| 2584 | Unsigned 3 bit integer (in the range 0 to 7) |
| 2585 | |
| 2586 | @item P@var{n} |
| 2587 | Constant @var{n}, where @var{n} is a single-digit constant in the range 0 to 4. |
| 2588 | |
| 2589 | @item PA |
| 2590 | An integer equal to one of the MACFLAG_XXX constants that is suitable for |
| 2591 | use with either accumulator. |
| 2592 | |
| 2593 | @item PB |
| 2594 | An integer equal to one of the MACFLAG_XXX constants that is suitable for |
| 2595 | use only with accumulator A1. |
| 2596 | |
| 2597 | @item M1 |
| 2598 | Constant 255. |
| 2599 | |
| 2600 | @item M2 |
| 2601 | Constant 65535. |
| 2602 | |
| 2603 | @item J |
| 2604 | An integer constant with exactly a single bit set. |
| 2605 | |
| 2606 | @item L |
| 2607 | An integer constant with all bits set except exactly one. |
| 2608 | |
| 2609 | @item H |
| 2610 | |
| 2611 | @item Q |
| 2612 | Any SYMBOL_REF. |
| 2613 | @end table |
| 2614 | |
| 2615 | @item M32C---@file{config/m32c/m32c.c} |
| 2616 | @table @code |
| 2617 | @item Rsp |
| 2618 | @itemx Rfb |
| 2619 | @itemx Rsb |
| 2620 | @samp{$sp}, @samp{$fb}, @samp{$sb}. |
| 2621 | |
| 2622 | @item Rcr |
| 2623 | Any control register, when they're 16 bits wide (nothing if control |
| 2624 | registers are 24 bits wide) |
| 2625 | |
| 2626 | @item Rcl |
| 2627 | Any control register, when they're 24 bits wide. |
| 2628 | |
| 2629 | @item R0w |
| 2630 | @itemx R1w |
| 2631 | @itemx R2w |
| 2632 | @itemx R3w |
| 2633 | $r0, $r1, $r2, $r3. |
| 2634 | |
| 2635 | @item R02 |
| 2636 | $r0 or $r2, or $r2r0 for 32 bit values. |
| 2637 | |
| 2638 | @item R13 |
| 2639 | $r1 or $r3, or $r3r1 for 32 bit values. |
| 2640 | |
| 2641 | @item Rdi |
| 2642 | A register that can hold a 64 bit value. |
| 2643 | |
| 2644 | @item Rhl |
| 2645 | $r0 or $r1 (registers with addressable high/low bytes) |
| 2646 | |
| 2647 | @item R23 |
| 2648 | $r2 or $r3 |
| 2649 | |
| 2650 | @item Raa |
| 2651 | Address registers |
| 2652 | |
| 2653 | @item Raw |
| 2654 | Address registers when they're 16 bits wide. |
| 2655 | |
| 2656 | @item Ral |
| 2657 | Address registers when they're 24 bits wide. |
| 2658 | |
| 2659 | @item Rqi |
| 2660 | Registers that can hold QI values. |
| 2661 | |
| 2662 | @item Rad |
| 2663 | Registers that can be used with displacements ($a0, $a1, $sb). |
| 2664 | |
| 2665 | @item Rsi |
| 2666 | Registers that can hold 32 bit values. |
| 2667 | |
| 2668 | @item Rhi |
| 2669 | Registers that can hold 16 bit values. |
| 2670 | |
| 2671 | @item Rhc |
| 2672 | Registers chat can hold 16 bit values, including all control |
| 2673 | registers. |
| 2674 | |
| 2675 | @item Rra |
| 2676 | $r0 through R1, plus $a0 and $a1. |
| 2677 | |
| 2678 | @item Rfl |
| 2679 | The flags register. |
| 2680 | |
| 2681 | @item Rmm |
| 2682 | The memory-based pseudo-registers $mem0 through $mem15. |
| 2683 | |
| 2684 | @item Rpi |
| 2685 | Registers that can hold pointers (16 bit registers for r8c, m16c; 24 |
| 2686 | bit registers for m32cm, m32c). |
| 2687 | |
| 2688 | @item Rpa |
| 2689 | Matches multiple registers in a PARALLEL to form a larger register. |
| 2690 | Used to match function return values. |
| 2691 | |
| 2692 | @item Is3 |
| 2693 | @minus{}8 @dots{} 7 |
| 2694 | |
| 2695 | @item IS1 |
| 2696 | @minus{}128 @dots{} 127 |
| 2697 | |
| 2698 | @item IS2 |
| 2699 | @minus{}32768 @dots{} 32767 |
| 2700 | |
| 2701 | @item IU2 |
| 2702 | 0 @dots{} 65535 |
| 2703 | |
| 2704 | @item In4 |
| 2705 | @minus{}8 @dots{} @minus{}1 or 1 @dots{} 8 |
| 2706 | |
| 2707 | @item In5 |
| 2708 | @minus{}16 @dots{} @minus{}1 or 1 @dots{} 16 |
| 2709 | |
| 2710 | @item In6 |
| 2711 | @minus{}32 @dots{} @minus{}1 or 1 @dots{} 32 |
| 2712 | |
| 2713 | @item IM2 |
| 2714 | @minus{}65536 @dots{} @minus{}1 |
| 2715 | |
| 2716 | @item Ilb |
| 2717 | An 8 bit value with exactly one bit set. |
| 2718 | |
| 2719 | @item Ilw |
| 2720 | A 16 bit value with exactly one bit set. |
| 2721 | |
| 2722 | @item Sd |
| 2723 | The common src/dest memory addressing modes. |
| 2724 | |
| 2725 | @item Sa |
| 2726 | Memory addressed using $a0 or $a1. |
| 2727 | |
| 2728 | @item Si |
| 2729 | Memory addressed with immediate addresses. |
| 2730 | |
| 2731 | @item Ss |
| 2732 | Memory addressed using the stack pointer ($sp). |
| 2733 | |
| 2734 | @item Sf |
| 2735 | Memory addressed using the frame base register ($fb). |
| 2736 | |
| 2737 | @item Ss |
| 2738 | Memory addressed using the small base register ($sb). |
| 2739 | |
| 2740 | @item S1 |
| 2741 | $r1h |
| 2742 | @end table |
| 2743 | |
| 2744 | @item MeP---@file{config/mep/constraints.md} |
| 2745 | @table @code |
| 2746 | |
| 2747 | @item a |
| 2748 | The $sp register. |
| 2749 | |
| 2750 | @item b |
| 2751 | The $tp register. |
| 2752 | |
| 2753 | @item c |
| 2754 | Any control register. |
| 2755 | |
| 2756 | @item d |
| 2757 | Either the $hi or the $lo register. |
| 2758 | |
| 2759 | @item em |
| 2760 | Coprocessor registers that can be directly loaded ($c0-$c15). |
| 2761 | |
| 2762 | @item ex |
| 2763 | Coprocessor registers that can be moved to each other. |
| 2764 | |
| 2765 | @item er |
| 2766 | Coprocessor registers that can be moved to core registers. |
| 2767 | |
| 2768 | @item h |
| 2769 | The $hi register. |
| 2770 | |
| 2771 | @item j |
| 2772 | The $rpc register. |
| 2773 | |
| 2774 | @item l |
| 2775 | The $lo register. |
| 2776 | |
| 2777 | @item t |
| 2778 | Registers which can be used in $tp-relative addressing. |
| 2779 | |
| 2780 | @item v |
| 2781 | The $gp register. |
| 2782 | |
| 2783 | @item x |
| 2784 | The coprocessor registers. |
| 2785 | |
| 2786 | @item y |
| 2787 | The coprocessor control registers. |
| 2788 | |
| 2789 | @item z |
| 2790 | The $0 register. |
| 2791 | |
| 2792 | @item A |
| 2793 | User-defined register set A. |
| 2794 | |
| 2795 | @item B |
| 2796 | User-defined register set B. |
| 2797 | |
| 2798 | @item C |
| 2799 | User-defined register set C. |
| 2800 | |
| 2801 | @item D |
| 2802 | User-defined register set D. |
| 2803 | |
| 2804 | @item I |
| 2805 | Offsets for $gp-rel addressing. |
| 2806 | |
| 2807 | @item J |
| 2808 | Constants that can be used directly with boolean insns. |
| 2809 | |
| 2810 | @item K |
| 2811 | Constants that can be moved directly to registers. |
| 2812 | |
| 2813 | @item L |
| 2814 | Small constants that can be added to registers. |
| 2815 | |
| 2816 | @item M |
| 2817 | Long shift counts. |
| 2818 | |
| 2819 | @item N |
| 2820 | Small constants that can be compared to registers. |
| 2821 | |
| 2822 | @item O |
| 2823 | Constants that can be loaded into the top half of registers. |
| 2824 | |
| 2825 | @item S |
| 2826 | Signed 8-bit immediates. |
| 2827 | |
| 2828 | @item T |
| 2829 | Symbols encoded for $tp-rel or $gp-rel addressing. |
| 2830 | |
| 2831 | @item U |
| 2832 | Non-constant addresses for loading/saving coprocessor registers. |
| 2833 | |
| 2834 | @item W |
| 2835 | The top half of a symbol's value. |
| 2836 | |
| 2837 | @item Y |
| 2838 | A register indirect address without offset. |
| 2839 | |
| 2840 | @item Z |
| 2841 | Symbolic references to the control bus. |
| 2842 | |
| 2843 | @end table |
| 2844 | |
| 2845 | @item MicroBlaze---@file{config/microblaze/constraints.md} |
| 2846 | @table @code |
| 2847 | @item d |
| 2848 | A general register (@code{r0} to @code{r31}). |
| 2849 | |
| 2850 | @item z |
| 2851 | A status register (@code{rmsr}, @code{$fcc1} to @code{$fcc7}). |
| 2852 | |
| 2853 | @end table |
| 2854 | |
| 2855 | @item MIPS---@file{config/mips/constraints.md} |
| 2856 | @table @code |
| 2857 | @item d |
| 2858 | An address register. This is equivalent to @code{r} unless |
| 2859 | generating MIPS16 code. |
| 2860 | |
| 2861 | @item f |
| 2862 | A floating-point register (if available). |
| 2863 | |
| 2864 | @item h |
| 2865 | Formerly the @code{hi} register. This constraint is no longer supported. |
| 2866 | |
| 2867 | @item l |
| 2868 | The @code{lo} register. Use this register to store values that are |
| 2869 | no bigger than a word. |
| 2870 | |
| 2871 | @item x |
| 2872 | The concatenated @code{hi} and @code{lo} registers. Use this register |
| 2873 | to store doubleword values. |
| 2874 | |
| 2875 | @item c |
| 2876 | A register suitable for use in an indirect jump. This will always be |
| 2877 | @code{$25} for @option{-mabicalls}. |
| 2878 | |
| 2879 | @item v |
| 2880 | Register @code{$3}. Do not use this constraint in new code; |
| 2881 | it is retained only for compatibility with glibc. |
| 2882 | |
| 2883 | @item y |
| 2884 | Equivalent to @code{r}; retained for backwards compatibility. |
| 2885 | |
| 2886 | @item z |
| 2887 | A floating-point condition code register. |
| 2888 | |
| 2889 | @item I |
| 2890 | A signed 16-bit constant (for arithmetic instructions). |
| 2891 | |
| 2892 | @item J |
| 2893 | Integer zero. |
| 2894 | |
| 2895 | @item K |
| 2896 | An unsigned 16-bit constant (for logic instructions). |
| 2897 | |
| 2898 | @item L |
| 2899 | A signed 32-bit constant in which the lower 16 bits are zero. |
| 2900 | Such constants can be loaded using @code{lui}. |
| 2901 | |
| 2902 | @item M |
| 2903 | A constant that cannot be loaded using @code{lui}, @code{addiu} |
| 2904 | or @code{ori}. |
| 2905 | |
| 2906 | @item N |
| 2907 | A constant in the range @minus{}65535 to @minus{}1 (inclusive). |
| 2908 | |
| 2909 | @item O |
| 2910 | A signed 15-bit constant. |
| 2911 | |
| 2912 | @item P |
| 2913 | A constant in the range 1 to 65535 (inclusive). |
| 2914 | |
| 2915 | @item G |
| 2916 | Floating-point zero. |
| 2917 | |
| 2918 | @item R |
| 2919 | An address that can be used in a non-macro load or store. |
| 2920 | @end table |
| 2921 | |
| 2922 | @item Motorola 680x0---@file{config/m68k/constraints.md} |
| 2923 | @table @code |
| 2924 | @item a |
| 2925 | Address register |
| 2926 | |
| 2927 | @item d |
| 2928 | Data register |
| 2929 | |
| 2930 | @item f |
| 2931 | 68881 floating-point register, if available |
| 2932 | |
| 2933 | @item I |
| 2934 | Integer in the range 1 to 8 |
| 2935 | |
| 2936 | @item J |
| 2937 | 16-bit signed number |
| 2938 | |
| 2939 | @item K |
| 2940 | Signed number whose magnitude is greater than 0x80 |
| 2941 | |
| 2942 | @item L |
| 2943 | Integer in the range @minus{}8 to @minus{}1 |
| 2944 | |
| 2945 | @item M |
| 2946 | Signed number whose magnitude is greater than 0x100 |
| 2947 | |
| 2948 | @item N |
| 2949 | Range 24 to 31, rotatert:SI 8 to 1 expressed as rotate |
| 2950 | |
| 2951 | @item O |
| 2952 | 16 (for rotate using swap) |
| 2953 | |
| 2954 | @item P |
| 2955 | Range 8 to 15, rotatert:HI 8 to 1 expressed as rotate |
| 2956 | |
| 2957 | @item R |
| 2958 | Numbers that mov3q can handle |
| 2959 | |
| 2960 | @item G |
| 2961 | Floating point constant that is not a 68881 constant |
| 2962 | |
| 2963 | @item S |
| 2964 | Operands that satisfy 'm' when -mpcrel is in effect |
| 2965 | |
| 2966 | @item T |
| 2967 | Operands that satisfy 's' when -mpcrel is not in effect |
| 2968 | |
| 2969 | @item Q |
| 2970 | Address register indirect addressing mode |
| 2971 | |
| 2972 | @item U |
| 2973 | Register offset addressing |
| 2974 | |
| 2975 | @item W |
| 2976 | const_call_operand |
| 2977 | |
| 2978 | @item Cs |
| 2979 | symbol_ref or const |
| 2980 | |
| 2981 | @item Ci |
| 2982 | const_int |
| 2983 | |
| 2984 | @item C0 |
| 2985 | const_int 0 |
| 2986 | |
| 2987 | @item Cj |
| 2988 | Range of signed numbers that don't fit in 16 bits |
| 2989 | |
| 2990 | @item Cmvq |
| 2991 | Integers valid for mvq |
| 2992 | |
| 2993 | @item Capsw |
| 2994 | Integers valid for a moveq followed by a swap |
| 2995 | |
| 2996 | @item Cmvz |
| 2997 | Integers valid for mvz |
| 2998 | |
| 2999 | @item Cmvs |
| 3000 | Integers valid for mvs |
| 3001 | |
| 3002 | @item Ap |
| 3003 | push_operand |
| 3004 | |
| 3005 | @item Ac |
| 3006 | Non-register operands allowed in clr |
| 3007 | |
| 3008 | @end table |
| 3009 | |
| 3010 | @item Moxie---@file{config/moxie/constraints.md} |
| 3011 | @table @code |
| 3012 | @item A |
| 3013 | An absolute address |
| 3014 | |
| 3015 | @item B |
| 3016 | An offset address |
| 3017 | |
| 3018 | @item W |
| 3019 | A register indirect memory operand |
| 3020 | |
| 3021 | @item I |
| 3022 | A constant in the range of 0 to 255. |
| 3023 | |
| 3024 | @item N |
| 3025 | A constant in the range of 0 to @minus{}255. |
| 3026 | |
| 3027 | @end table |
| 3028 | |
| 3029 | @item PDP-11---@file{config/pdp11/constraints.md} |
| 3030 | @table @code |
| 3031 | @item a |
| 3032 | Floating point registers AC0 through AC3. These can be loaded from/to |
| 3033 | memory with a single instruction. |
| 3034 | |
| 3035 | @item d |
| 3036 | Odd numbered general registers (R1, R3, R5). These are used for |
| 3037 | 16-bit multiply operations. |
| 3038 | |
| 3039 | @item f |
| 3040 | Any of the floating point registers (AC0 through AC5). |
| 3041 | |
| 3042 | @item G |
| 3043 | Floating point constant 0. |
| 3044 | |
| 3045 | @item I |
| 3046 | An integer constant that fits in 16 bits. |
| 3047 | |
| 3048 | @item J |
| 3049 | An integer constant whose low order 16 bits are zero. |
| 3050 | |
| 3051 | @item K |
| 3052 | An integer constant that does not meet the constraints for codes |
| 3053 | @samp{I} or @samp{J}. |
| 3054 | |
| 3055 | @item L |
| 3056 | The integer constant 1. |
| 3057 | |
| 3058 | @item M |
| 3059 | The integer constant @minus{}1. |
| 3060 | |
| 3061 | @item N |
| 3062 | The integer constant 0. |
| 3063 | |
| 3064 | @item O |
| 3065 | Integer constants @minus{}4 through @minus{}1 and 1 through 4; shifts by these |
| 3066 | amounts are handled as multiple single-bit shifts rather than a single |
| 3067 | variable-length shift. |
| 3068 | |
| 3069 | @item Q |
| 3070 | A memory reference which requires an additional word (address or |
| 3071 | offset) after the opcode. |
| 3072 | |
| 3073 | @item R |
| 3074 | A memory reference that is encoded within the opcode. |
| 3075 | |
| 3076 | @end table |
| 3077 | |
| 3078 | @item RL78---@file{config/rl78/constraints.md} |
| 3079 | @table @code |
| 3080 | |
| 3081 | @item Int3 |
| 3082 | An integer constant in the range 1 @dots{} 7. |
| 3083 | @item Int8 |
| 3084 | An integer constant in the range 0 @dots{} 255. |
| 3085 | @item J |
| 3086 | An integer constant in the range @minus{}255 @dots{} 0 |
| 3087 | @item K |
| 3088 | The integer constant 1. |
| 3089 | @item L |
| 3090 | The integer constant -1. |
| 3091 | @item M |
| 3092 | The integer constant 0. |
| 3093 | @item N |
| 3094 | The integer constant 2. |
| 3095 | @item O |
| 3096 | The integer constant -2. |
| 3097 | @item P |
| 3098 | An integer constant in the range 1 @dots{} 15. |
| 3099 | @item Qbi |
| 3100 | The built-in compare types--eq, ne, gtu, ltu, geu, and leu. |
| 3101 | @item Qsc |
| 3102 | The synthetic compare types--gt, lt, ge, and le. |
| 3103 | @item Wab |
| 3104 | A memory reference with an absolute address. |
| 3105 | @item Wbc |
| 3106 | A memory reference using @code{BC} as a base register, with an optional offset. |
| 3107 | @item Wca |
| 3108 | A memory reference using @code{AX}, @code{BC}, @code{DE}, or @code{HL} for the address, for calls. |
| 3109 | @item Wcv |
| 3110 | A memory reference using any 16-bit register pair for the address, for calls. |
| 3111 | @item Wd2 |
| 3112 | A memory reference using @code{DE} as a base register, with an optional offset. |
| 3113 | @item Wde |
| 3114 | A memory reference using @code{DE} as a base register, without any offset. |
| 3115 | @item Wfr |
| 3116 | Any memory reference to an address in the far address space. |
| 3117 | @item Wh1 |
| 3118 | A memory reference using @code{HL} as a base register, with an optional one-byte offset. |
| 3119 | @item Whb |
| 3120 | A memory reference using @code{HL} as a base register, with @code{B} or @code{C} as the index register. |
| 3121 | @item Whl |
| 3122 | A memory reference using @code{HL} as a base register, without any offset. |
| 3123 | @item Ws1 |
| 3124 | A memory reference using @code{SP} as a base register, with an optional one-byte offset. |
| 3125 | @item Y |
| 3126 | Any memory reference to an address in the near address space. |
| 3127 | @item A |
| 3128 | The @code{AX} register. |
| 3129 | @item B |
| 3130 | The @code{BC} register. |
| 3131 | @item D |
| 3132 | The @code{DE} register. |
| 3133 | @item R |
| 3134 | @code{A} through @code{L} registers. |
| 3135 | @item S |
| 3136 | The @code{SP} register. |
| 3137 | @item T |
| 3138 | The @code{HL} register. |
| 3139 | @item Z08W |
| 3140 | The 16-bit @code{R8} register. |
| 3141 | @item Z10W |
| 3142 | The 16-bit @code{R10} register. |
| 3143 | @item Zint |
| 3144 | The registers reserved for interrupts (@code{R24} to @code{R31}). |
| 3145 | @item a |
| 3146 | The @code{A} register. |
| 3147 | @item b |
| 3148 | The @code{B} register. |
| 3149 | @item c |
| 3150 | The @code{C} register. |
| 3151 | @item d |
| 3152 | The @code{D} register. |
| 3153 | @item e |
| 3154 | The @code{E} register. |
| 3155 | @item h |
| 3156 | The @code{H} register. |
| 3157 | @item l |
| 3158 | The @code{L} register. |
| 3159 | @item v |
| 3160 | The virtual registers. |
| 3161 | @item w |
| 3162 | The @code{PSW} register. |
| 3163 | @item x |
| 3164 | The @code{X} register. |
| 3165 | |
| 3166 | @end table |
| 3167 | |
| 3168 | @item RX---@file{config/rx/constraints.md} |
| 3169 | @table @code |
| 3170 | @item Q |
| 3171 | An address which does not involve register indirect addressing or |
| 3172 | pre/post increment/decrement addressing. |
| 3173 | |
| 3174 | @item Symbol |
| 3175 | A symbol reference. |
| 3176 | |
| 3177 | @item Int08 |
| 3178 | A constant in the range @minus{}256 to 255, inclusive. |
| 3179 | |
| 3180 | @item Sint08 |
| 3181 | A constant in the range @minus{}128 to 127, inclusive. |
| 3182 | |
| 3183 | @item Sint16 |
| 3184 | A constant in the range @minus{}32768 to 32767, inclusive. |
| 3185 | |
| 3186 | @item Sint24 |
| 3187 | A constant in the range @minus{}8388608 to 8388607, inclusive. |
| 3188 | |
| 3189 | @item Uint04 |
| 3190 | A constant in the range 0 to 15, inclusive. |
| 3191 | |
| 3192 | @end table |
| 3193 | |
| 3194 | @need 1000 |
| 3195 | @item SPARC---@file{config/sparc/sparc.h} |
| 3196 | @table @code |
| 3197 | @item f |
| 3198 | Floating-point register on the SPARC-V8 architecture and |
| 3199 | lower floating-point register on the SPARC-V9 architecture. |
| 3200 | |
| 3201 | @item e |
| 3202 | Floating-point register. It is equivalent to @samp{f} on the |
| 3203 | SPARC-V8 architecture and contains both lower and upper |
| 3204 | floating-point registers on the SPARC-V9 architecture. |
| 3205 | |
| 3206 | @item c |
| 3207 | Floating-point condition code register. |
| 3208 | |
| 3209 | @item d |
| 3210 | Lower floating-point register. It is only valid on the SPARC-V9 |
| 3211 | architecture when the Visual Instruction Set is available. |
| 3212 | |
| 3213 | @item b |
| 3214 | Floating-point register. It is only valid on the SPARC-V9 architecture |
| 3215 | when the Visual Instruction Set is available. |
| 3216 | |
| 3217 | @item h |
| 3218 | 64-bit global or out register for the SPARC-V8+ architecture. |
| 3219 | |
| 3220 | @item D |
| 3221 | A vector constant |
| 3222 | |
| 3223 | @item I |
| 3224 | Signed 13-bit constant |
| 3225 | |
| 3226 | @item J |
| 3227 | Zero |
| 3228 | |
| 3229 | @item K |
| 3230 | 32-bit constant with the low 12 bits clear (a constant that can be |
| 3231 | loaded with the @code{sethi} instruction) |
| 3232 | |
| 3233 | @item L |
| 3234 | A constant in the range supported by @code{movcc} instructions |
| 3235 | |
| 3236 | @item M |
| 3237 | A constant in the range supported by @code{movrcc} instructions |
| 3238 | |
| 3239 | @item N |
| 3240 | Same as @samp{K}, except that it verifies that bits that are not in the |
| 3241 | lower 32-bit range are all zero. Must be used instead of @samp{K} for |
| 3242 | modes wider than @code{SImode} |
| 3243 | |
| 3244 | @item O |
| 3245 | The constant 4096 |
| 3246 | |
| 3247 | @item G |
| 3248 | Floating-point zero |
| 3249 | |
| 3250 | @item H |
| 3251 | Signed 13-bit constant, sign-extended to 32 or 64 bits |
| 3252 | |
| 3253 | @item Q |
| 3254 | Floating-point constant whose integral representation can |
| 3255 | be moved into an integer register using a single sethi |
| 3256 | instruction |
| 3257 | |
| 3258 | @item R |
| 3259 | Floating-point constant whose integral representation can |
| 3260 | be moved into an integer register using a single mov |
| 3261 | instruction |
| 3262 | |
| 3263 | @item S |
| 3264 | Floating-point constant whose integral representation can |
| 3265 | be moved into an integer register using a high/lo_sum |
| 3266 | instruction sequence |
| 3267 | |
| 3268 | @item T |
| 3269 | Memory address aligned to an 8-byte boundary |
| 3270 | |
| 3271 | @item U |
| 3272 | Even register |
| 3273 | |
| 3274 | @item W |
| 3275 | Memory address for @samp{e} constraint registers |
| 3276 | |
| 3277 | @item Y |
| 3278 | Vector zero |
| 3279 | |
| 3280 | @end table |
| 3281 | |
| 3282 | @item SPU---@file{config/spu/spu.h} |
| 3283 | @table @code |
| 3284 | @item a |
| 3285 | An immediate which can be loaded with the il/ila/ilh/ilhu instructions. const_int is treated as a 64 bit value. |
| 3286 | |
| 3287 | @item c |
| 3288 | An immediate for and/xor/or instructions. const_int is treated as a 64 bit value. |
| 3289 | |
| 3290 | @item d |
| 3291 | An immediate for the @code{iohl} instruction. const_int is treated as a 64 bit value. |
| 3292 | |
| 3293 | @item f |
| 3294 | An immediate which can be loaded with @code{fsmbi}. |
| 3295 | |
| 3296 | @item A |
| 3297 | An immediate which can be loaded with the il/ila/ilh/ilhu instructions. const_int is treated as a 32 bit value. |
| 3298 | |
| 3299 | @item B |
| 3300 | An immediate for most arithmetic instructions. const_int is treated as a 32 bit value. |
| 3301 | |
| 3302 | @item C |
| 3303 | An immediate for and/xor/or instructions. const_int is treated as a 32 bit value. |
| 3304 | |
| 3305 | @item D |
| 3306 | An immediate for the @code{iohl} instruction. const_int is treated as a 32 bit value. |
| 3307 | |
| 3308 | @item I |
| 3309 | A constant in the range [@minus{}64, 63] for shift/rotate instructions. |
| 3310 | |
| 3311 | @item J |
| 3312 | An unsigned 7-bit constant for conversion/nop/channel instructions. |
| 3313 | |
| 3314 | @item K |
| 3315 | A signed 10-bit constant for most arithmetic instructions. |
| 3316 | |
| 3317 | @item M |
| 3318 | A signed 16 bit immediate for @code{stop}. |
| 3319 | |
| 3320 | @item N |
| 3321 | An unsigned 16-bit constant for @code{iohl} and @code{fsmbi}. |
| 3322 | |
| 3323 | @item O |
| 3324 | An unsigned 7-bit constant whose 3 least significant bits are 0. |
| 3325 | |
| 3326 | @item P |
| 3327 | An unsigned 3-bit constant for 16-byte rotates and shifts |
| 3328 | |
| 3329 | @item R |
| 3330 | Call operand, reg, for indirect calls |
| 3331 | |
| 3332 | @item S |
| 3333 | Call operand, symbol, for relative calls. |
| 3334 | |
| 3335 | @item T |
| 3336 | Call operand, const_int, for absolute calls. |
| 3337 | |
| 3338 | @item U |
| 3339 | An immediate which can be loaded with the il/ila/ilh/ilhu instructions. const_int is sign extended to 128 bit. |
| 3340 | |
| 3341 | @item W |
| 3342 | An immediate for shift and rotate instructions. const_int is treated as a 32 bit value. |
| 3343 | |
| 3344 | @item Y |
| 3345 | An immediate for and/xor/or instructions. const_int is sign extended as a 128 bit. |
| 3346 | |
| 3347 | @item Z |
| 3348 | An immediate for the @code{iohl} instruction. const_int is sign extended to 128 bit. |
| 3349 | |
| 3350 | @end table |
| 3351 | |
| 3352 | @item S/390 and zSeries---@file{config/s390/s390.h} |
| 3353 | @table @code |
| 3354 | @item a |
| 3355 | Address register (general purpose register except r0) |
| 3356 | |
| 3357 | @item c |
| 3358 | Condition code register |
| 3359 | |
| 3360 | @item d |
| 3361 | Data register (arbitrary general purpose register) |
| 3362 | |
| 3363 | @item f |
| 3364 | Floating-point register |
| 3365 | |
| 3366 | @item I |
| 3367 | Unsigned 8-bit constant (0--255) |
| 3368 | |
| 3369 | @item J |
| 3370 | Unsigned 12-bit constant (0--4095) |
| 3371 | |
| 3372 | @item K |
| 3373 | Signed 16-bit constant (@minus{}32768--32767) |
| 3374 | |
| 3375 | @item L |
| 3376 | Value appropriate as displacement. |
| 3377 | @table @code |
| 3378 | @item (0..4095) |
| 3379 | for short displacement |
| 3380 | @item (@minus{}524288..524287) |
| 3381 | for long displacement |
| 3382 | @end table |
| 3383 | |
| 3384 | @item M |
| 3385 | Constant integer with a value of 0x7fffffff. |
| 3386 | |
| 3387 | @item N |
| 3388 | Multiple letter constraint followed by 4 parameter letters. |
| 3389 | @table @code |
| 3390 | @item 0..9: |
| 3391 | number of the part counting from most to least significant |
| 3392 | @item H,Q: |
| 3393 | mode of the part |
| 3394 | @item D,S,H: |
| 3395 | mode of the containing operand |
| 3396 | @item 0,F: |
| 3397 | value of the other parts (F---all bits set) |
| 3398 | @end table |
| 3399 | The constraint matches if the specified part of a constant |
| 3400 | has a value different from its other parts. |
| 3401 | |
| 3402 | @item Q |
| 3403 | Memory reference without index register and with short displacement. |
| 3404 | |
| 3405 | @item R |
| 3406 | Memory reference with index register and short displacement. |
| 3407 | |
| 3408 | @item S |
| 3409 | Memory reference without index register but with long displacement. |
| 3410 | |
| 3411 | @item T |
| 3412 | Memory reference with index register and long displacement. |
| 3413 | |
| 3414 | @item U |
| 3415 | Pointer with short displacement. |
| 3416 | |
| 3417 | @item W |
| 3418 | Pointer with long displacement. |
| 3419 | |
| 3420 | @item Y |
| 3421 | Shift count operand. |
| 3422 | |
| 3423 | @end table |
| 3424 | |
| 3425 | @item Score family---@file{config/score/score.h} |
| 3426 | @table @code |
| 3427 | @item d |
| 3428 | Registers from r0 to r32. |
| 3429 | |
| 3430 | @item e |
| 3431 | Registers from r0 to r16. |
| 3432 | |
| 3433 | @item t |
| 3434 | r8---r11 or r22---r27 registers. |
| 3435 | |
| 3436 | @item h |
| 3437 | hi register. |
| 3438 | |
| 3439 | @item l |
| 3440 | lo register. |
| 3441 | |
| 3442 | @item x |
| 3443 | hi + lo register. |
| 3444 | |
| 3445 | @item q |
| 3446 | cnt register. |
| 3447 | |
| 3448 | @item y |
| 3449 | lcb register. |
| 3450 | |
| 3451 | @item z |
| 3452 | scb register. |
| 3453 | |
| 3454 | @item a |
| 3455 | cnt + lcb + scb register. |
| 3456 | |
| 3457 | @item c |
| 3458 | cr0---cr15 register. |
| 3459 | |
| 3460 | @item b |
| 3461 | cp1 registers. |
| 3462 | |
| 3463 | @item f |
| 3464 | cp2 registers. |
| 3465 | |
| 3466 | @item i |
| 3467 | cp3 registers. |
| 3468 | |
| 3469 | @item j |
| 3470 | cp1 + cp2 + cp3 registers. |
| 3471 | |
| 3472 | @item I |
| 3473 | High 16-bit constant (32-bit constant with 16 LSBs zero). |
| 3474 | |
| 3475 | @item J |
| 3476 | Unsigned 5 bit integer (in the range 0 to 31). |
| 3477 | |
| 3478 | @item K |
| 3479 | Unsigned 16 bit integer (in the range 0 to 65535). |
| 3480 | |
| 3481 | @item L |
| 3482 | Signed 16 bit integer (in the range @minus{}32768 to 32767). |
| 3483 | |
| 3484 | @item M |
| 3485 | Unsigned 14 bit integer (in the range 0 to 16383). |
| 3486 | |
| 3487 | @item N |
| 3488 | Signed 14 bit integer (in the range @minus{}8192 to 8191). |
| 3489 | |
| 3490 | @item Z |
| 3491 | Any SYMBOL_REF. |
| 3492 | @end table |
| 3493 | |
| 3494 | @item Xstormy16---@file{config/stormy16/stormy16.h} |
| 3495 | @table @code |
| 3496 | @item a |
| 3497 | Register r0. |
| 3498 | |
| 3499 | @item b |
| 3500 | Register r1. |
| 3501 | |
| 3502 | @item c |
| 3503 | Register r2. |
| 3504 | |
| 3505 | @item d |
| 3506 | Register r8. |
| 3507 | |
| 3508 | @item e |
| 3509 | Registers r0 through r7. |
| 3510 | |
| 3511 | @item t |
| 3512 | Registers r0 and r1. |
| 3513 | |
| 3514 | @item y |
| 3515 | The carry register. |
| 3516 | |
| 3517 | @item z |
| 3518 | Registers r8 and r9. |
| 3519 | |
| 3520 | @item I |
| 3521 | A constant between 0 and 3 inclusive. |
| 3522 | |
| 3523 | @item J |
| 3524 | A constant that has exactly one bit set. |
| 3525 | |
| 3526 | @item K |
| 3527 | A constant that has exactly one bit clear. |
| 3528 | |
| 3529 | @item L |
| 3530 | A constant between 0 and 255 inclusive. |
| 3531 | |
| 3532 | @item M |
| 3533 | A constant between @minus{}255 and 0 inclusive. |
| 3534 | |
| 3535 | @item N |
| 3536 | A constant between @minus{}3 and 0 inclusive. |
| 3537 | |
| 3538 | @item O |
| 3539 | A constant between 1 and 4 inclusive. |
| 3540 | |
| 3541 | @item P |
| 3542 | A constant between @minus{}4 and @minus{}1 inclusive. |
| 3543 | |
| 3544 | @item Q |
| 3545 | A memory reference that is a stack push. |
| 3546 | |
| 3547 | @item R |
| 3548 | A memory reference that is a stack pop. |
| 3549 | |
| 3550 | @item S |
| 3551 | A memory reference that refers to a constant address of known value. |
| 3552 | |
| 3553 | @item T |
| 3554 | The register indicated by Rx (not implemented yet). |
| 3555 | |
| 3556 | @item U |
| 3557 | A constant that is not between 2 and 15 inclusive. |
| 3558 | |
| 3559 | @item Z |
| 3560 | The constant 0. |
| 3561 | |
| 3562 | @end table |
| 3563 | |
| 3564 | @item TI C6X family---@file{config/c6x/constraints.md} |
| 3565 | @table @code |
| 3566 | @item a |
| 3567 | Register file A (A0--A31). |
| 3568 | |
| 3569 | @item b |
| 3570 | Register file B (B0--B31). |
| 3571 | |
| 3572 | @item A |
| 3573 | Predicate registers in register file A (A0--A2 on C64X and |
| 3574 | higher, A1 and A2 otherwise). |
| 3575 | |
| 3576 | @item B |
| 3577 | Predicate registers in register file B (B0--B2). |
| 3578 | |
| 3579 | @item C |
| 3580 | A call-used register in register file B (B0--B9, B16--B31). |
| 3581 | |
| 3582 | @item Da |
| 3583 | Register file A, excluding predicate registers (A3--A31, |
| 3584 | plus A0 if not C64X or higher). |
| 3585 | |
| 3586 | @item Db |
| 3587 | Register file B, excluding predicate registers (B3--B31). |
| 3588 | |
| 3589 | @item Iu4 |
| 3590 | Integer constant in the range 0 @dots{} 15. |
| 3591 | |
| 3592 | @item Iu5 |
| 3593 | Integer constant in the range 0 @dots{} 31. |
| 3594 | |
| 3595 | @item In5 |
| 3596 | Integer constant in the range @minus{}31 @dots{} 0. |
| 3597 | |
| 3598 | @item Is5 |
| 3599 | Integer constant in the range @minus{}16 @dots{} 15. |
| 3600 | |
| 3601 | @item I5x |
| 3602 | Integer constant that can be the operand of an ADDA or a SUBA insn. |
| 3603 | |
| 3604 | @item IuB |
| 3605 | Integer constant in the range 0 @dots{} 65535. |
| 3606 | |
| 3607 | @item IsB |
| 3608 | Integer constant in the range @minus{}32768 @dots{} 32767. |
| 3609 | |
| 3610 | @item IsC |
| 3611 | Integer constant in the range @math{-2^{20}} @dots{} @math{2^{20} - 1}. |
| 3612 | |
| 3613 | @item Jc |
| 3614 | Integer constant that is a valid mask for the clr instruction. |
| 3615 | |
| 3616 | @item Js |
| 3617 | Integer constant that is a valid mask for the set instruction. |
| 3618 | |
| 3619 | @item Q |
| 3620 | Memory location with A base register. |
| 3621 | |
| 3622 | @item R |
| 3623 | Memory location with B base register. |
| 3624 | |
| 3625 | @ifset INTERNALS |
| 3626 | @item S0 |
| 3627 | On C64x+ targets, a GP-relative small data reference. |
| 3628 | |
| 3629 | @item S1 |
| 3630 | Any kind of @code{SYMBOL_REF}, for use in a call address. |
| 3631 | |
| 3632 | @item Si |
| 3633 | Any kind of immediate operand, unless it matches the S0 constraint. |
| 3634 | |
| 3635 | @item T |
| 3636 | Memory location with B base register, but not using a long offset. |
| 3637 | |
| 3638 | @item W |
| 3639 | A memory operand with an address that can't be used in an unaligned access. |
| 3640 | |
| 3641 | @end ifset |
| 3642 | @item Z |
| 3643 | Register B14 (aka DP). |
| 3644 | |
| 3645 | @end table |
| 3646 | |
| 3647 | @item TILE-Gx---@file{config/tilegx/constraints.md} |
| 3648 | @table @code |
| 3649 | @item R00 |
| 3650 | @itemx R01 |
| 3651 | @itemx R02 |
| 3652 | @itemx R03 |
| 3653 | @itemx R04 |
| 3654 | @itemx R05 |
| 3655 | @itemx R06 |
| 3656 | @itemx R07 |
| 3657 | @itemx R08 |
| 3658 | @itemx R09 |
| 3659 | @itemx R10 |
| 3660 | Each of these represents a register constraint for an individual |
| 3661 | register, from r0 to r10. |
| 3662 | |
| 3663 | @item I |
| 3664 | Signed 8-bit integer constant. |
| 3665 | |
| 3666 | @item J |
| 3667 | Signed 16-bit integer constant. |
| 3668 | |
| 3669 | @item K |
| 3670 | Unsigned 16-bit integer constant. |
| 3671 | |
| 3672 | @item L |
| 3673 | Integer constant that fits in one signed byte when incremented by one |
| 3674 | (@minus{}129 @dots{} 126). |
| 3675 | |
| 3676 | @item m |
| 3677 | Memory operand. If used together with @samp{<} or @samp{>}, the |
| 3678 | operand can have postincrement which requires printing with @samp{%In} |
| 3679 | and @samp{%in} on TILE-Gx. For example: |
| 3680 | |
| 3681 | @smallexample |
| 3682 | asm ("st_add %I0,%1,%i0" : "=m<>" (*mem) : "r" (val)); |
| 3683 | @end smallexample |
| 3684 | |
| 3685 | @item M |
| 3686 | A bit mask suitable for the BFINS instruction. |
| 3687 | |
| 3688 | @item N |
| 3689 | Integer constant that is a byte tiled out eight times. |
| 3690 | |
| 3691 | @item O |
| 3692 | The integer zero constant. |
| 3693 | |
| 3694 | @item P |
| 3695 | Integer constant that is a sign-extended byte tiled out as four shorts. |
| 3696 | |
| 3697 | @item Q |
| 3698 | Integer constant that fits in one signed byte when incremented |
| 3699 | (@minus{}129 @dots{} 126), but excluding -1. |
| 3700 | |
| 3701 | @item S |
| 3702 | Integer constant that has all 1 bits consecutive and starting at bit 0. |
| 3703 | |
| 3704 | @item T |
| 3705 | A 16-bit fragment of a got, tls, or pc-relative reference. |
| 3706 | |
| 3707 | @item U |
| 3708 | Memory operand except postincrement. This is roughly the same as |
| 3709 | @samp{m} when not used together with @samp{<} or @samp{>}. |
| 3710 | |
| 3711 | @item W |
| 3712 | An 8-element vector constant with identical elements. |
| 3713 | |
| 3714 | @item Y |
| 3715 | A 4-element vector constant with identical elements. |
| 3716 | |
| 3717 | @item Z0 |
| 3718 | The integer constant 0xffffffff. |
| 3719 | |
| 3720 | @item Z1 |
| 3721 | The integer constant 0xffffffff00000000. |
| 3722 | |
| 3723 | @end table |
| 3724 | |
| 3725 | @item TILEPro---@file{config/tilepro/constraints.md} |
| 3726 | @table @code |
| 3727 | @item R00 |
| 3728 | @itemx R01 |
| 3729 | @itemx R02 |
| 3730 | @itemx R03 |
| 3731 | @itemx R04 |
| 3732 | @itemx R05 |
| 3733 | @itemx R06 |
| 3734 | @itemx R07 |
| 3735 | @itemx R08 |
| 3736 | @itemx R09 |
| 3737 | @itemx R10 |
| 3738 | Each of these represents a register constraint for an individual |
| 3739 | register, from r0 to r10. |
| 3740 | |
| 3741 | @item I |
| 3742 | Signed 8-bit integer constant. |
| 3743 | |
| 3744 | @item J |
| 3745 | Signed 16-bit integer constant. |
| 3746 | |
| 3747 | @item K |
| 3748 | Nonzero integer constant with low 16 bits zero. |
| 3749 | |
| 3750 | @item L |
| 3751 | Integer constant that fits in one signed byte when incremented by one |
| 3752 | (@minus{}129 @dots{} 126). |
| 3753 | |
| 3754 | @item m |
| 3755 | Memory operand. If used together with @samp{<} or @samp{>}, the |
| 3756 | operand can have postincrement which requires printing with @samp{%In} |
| 3757 | and @samp{%in} on TILEPro. For example: |
| 3758 | |
| 3759 | @smallexample |
| 3760 | asm ("swadd %I0,%1,%i0" : "=m<>" (mem) : "r" (val)); |
| 3761 | @end smallexample |
| 3762 | |
| 3763 | @item M |
| 3764 | A bit mask suitable for the MM instruction. |
| 3765 | |
| 3766 | @item N |
| 3767 | Integer constant that is a byte tiled out four times. |
| 3768 | |
| 3769 | @item O |
| 3770 | The integer zero constant. |
| 3771 | |
| 3772 | @item P |
| 3773 | Integer constant that is a sign-extended byte tiled out as two shorts. |
| 3774 | |
| 3775 | @item Q |
| 3776 | Integer constant that fits in one signed byte when incremented |
| 3777 | (@minus{}129 @dots{} 126), but excluding -1. |
| 3778 | |
| 3779 | @item T |
| 3780 | A symbolic operand, or a 16-bit fragment of a got, tls, or pc-relative |
| 3781 | reference. |
| 3782 | |
| 3783 | @item U |
| 3784 | Memory operand except postincrement. This is roughly the same as |
| 3785 | @samp{m} when not used together with @samp{<} or @samp{>}. |
| 3786 | |
| 3787 | @item W |
| 3788 | A 4-element vector constant with identical elements. |
| 3789 | |
| 3790 | @item Y |
| 3791 | A 2-element vector constant with identical elements. |
| 3792 | |
| 3793 | @end table |
| 3794 | |
| 3795 | @item Xtensa---@file{config/xtensa/constraints.md} |
| 3796 | @table @code |
| 3797 | @item a |
| 3798 | General-purpose 32-bit register |
| 3799 | |
| 3800 | @item b |
| 3801 | One-bit boolean register |
| 3802 | |
| 3803 | @item A |
| 3804 | MAC16 40-bit accumulator register |
| 3805 | |
| 3806 | @item I |
| 3807 | Signed 12-bit integer constant, for use in MOVI instructions |
| 3808 | |
| 3809 | @item J |
| 3810 | Signed 8-bit integer constant, for use in ADDI instructions |
| 3811 | |
| 3812 | @item K |
| 3813 | Integer constant valid for BccI instructions |
| 3814 | |
| 3815 | @item L |
| 3816 | Unsigned constant valid for BccUI instructions |
| 3817 | |
| 3818 | @end table |
| 3819 | |
| 3820 | @end table |
| 3821 | |
| 3822 | @ifset INTERNALS |
| 3823 | @node Disable Insn Alternatives |
| 3824 | @subsection Disable insn alternatives using the @code{enabled} attribute |
| 3825 | @cindex enabled |
| 3826 | |
| 3827 | The @code{enabled} insn attribute may be used to disable certain insn |
| 3828 | alternatives for machine-specific reasons. This is useful when adding |
| 3829 | new instructions to an existing pattern which are only available for |
| 3830 | certain cpu architecture levels as specified with the @code{-march=} |
| 3831 | option. |
| 3832 | |
| 3833 | If an insn alternative is disabled, then it will never be used. The |
| 3834 | compiler treats the constraints for the disabled alternative as |
| 3835 | unsatisfiable. |
| 3836 | |
| 3837 | In order to make use of the @code{enabled} attribute a back end has to add |
| 3838 | in the machine description files: |
| 3839 | |
| 3840 | @enumerate |
| 3841 | @item |
| 3842 | A definition of the @code{enabled} insn attribute. The attribute is |
| 3843 | defined as usual using the @code{define_attr} command. This |
| 3844 | definition should be based on other insn attributes and/or target flags. |
| 3845 | The @code{enabled} attribute is a numeric attribute and should evaluate to |
| 3846 | @code{(const_int 1)} for an enabled alternative and to |
| 3847 | @code{(const_int 0)} otherwise. |
| 3848 | @item |
| 3849 | A definition of another insn attribute used to describe for what |
| 3850 | reason an insn alternative might be available or |
| 3851 | not. E.g. @code{cpu_facility} as in the example below. |
| 3852 | @item |
| 3853 | An assignment for the second attribute to each insn definition |
| 3854 | combining instructions which are not all available under the same |
| 3855 | circumstances. (Note: It obviously only makes sense for definitions |
| 3856 | with more than one alternative. Otherwise the insn pattern should be |
| 3857 | disabled or enabled using the insn condition.) |
| 3858 | @end enumerate |
| 3859 | |
| 3860 | E.g. the following two patterns could easily be merged using the @code{enabled} |
| 3861 | attribute: |
| 3862 | |
| 3863 | @smallexample |
| 3864 | |
| 3865 | (define_insn "*movdi_old" |
| 3866 | [(set (match_operand:DI 0 "register_operand" "=d") |
| 3867 | (match_operand:DI 1 "register_operand" " d"))] |
| 3868 | "!TARGET_NEW" |
| 3869 | "lgr %0,%1") |
| 3870 | |
| 3871 | (define_insn "*movdi_new" |
| 3872 | [(set (match_operand:DI 0 "register_operand" "=d,f,d") |
| 3873 | (match_operand:DI 1 "register_operand" " d,d,f"))] |
| 3874 | "TARGET_NEW" |
| 3875 | "@@ |
| 3876 | lgr %0,%1 |
| 3877 | ldgr %0,%1 |
| 3878 | lgdr %0,%1") |
| 3879 | |
| 3880 | @end smallexample |
| 3881 | |
| 3882 | to: |
| 3883 | |
| 3884 | @smallexample |
| 3885 | |
| 3886 | (define_insn "*movdi_combined" |
| 3887 | [(set (match_operand:DI 0 "register_operand" "=d,f,d") |
| 3888 | (match_operand:DI 1 "register_operand" " d,d,f"))] |
| 3889 | "" |
| 3890 | "@@ |
| 3891 | lgr %0,%1 |
| 3892 | ldgr %0,%1 |
| 3893 | lgdr %0,%1" |
| 3894 | [(set_attr "cpu_facility" "*,new,new")]) |
| 3895 | |
| 3896 | @end smallexample |
| 3897 | |
| 3898 | with the @code{enabled} attribute defined like this: |
| 3899 | |
| 3900 | @smallexample |
| 3901 | |
| 3902 | (define_attr "cpu_facility" "standard,new" (const_string "standard")) |
| 3903 | |
| 3904 | (define_attr "enabled" "" |
| 3905 | (cond [(eq_attr "cpu_facility" "standard") (const_int 1) |
| 3906 | (and (eq_attr "cpu_facility" "new") |
| 3907 | (ne (symbol_ref "TARGET_NEW") (const_int 0))) |
| 3908 | (const_int 1)] |
| 3909 | (const_int 0))) |
| 3910 | |
| 3911 | @end smallexample |
| 3912 | |
| 3913 | @end ifset |
| 3914 | |
| 3915 | @ifset INTERNALS |
| 3916 | @node Define Constraints |
| 3917 | @subsection Defining Machine-Specific Constraints |
| 3918 | @cindex defining constraints |
| 3919 | @cindex constraints, defining |
| 3920 | |
| 3921 | Machine-specific constraints fall into two categories: register and |
| 3922 | non-register constraints. Within the latter category, constraints |
| 3923 | which allow subsets of all possible memory or address operands should |
| 3924 | be specially marked, to give @code{reload} more information. |
| 3925 | |
| 3926 | Machine-specific constraints can be given names of arbitrary length, |
| 3927 | but they must be entirely composed of letters, digits, underscores |
| 3928 | (@samp{_}), and angle brackets (@samp{< >}). Like C identifiers, they |
| 3929 | must begin with a letter or underscore. |
| 3930 | |
| 3931 | In order to avoid ambiguity in operand constraint strings, no |
| 3932 | constraint can have a name that begins with any other constraint's |
| 3933 | name. For example, if @code{x} is defined as a constraint name, |
| 3934 | @code{xy} may not be, and vice versa. As a consequence of this rule, |
| 3935 | no constraint may begin with one of the generic constraint letters: |
| 3936 | @samp{E F V X g i m n o p r s}. |
| 3937 | |
| 3938 | Register constraints correspond directly to register classes. |
| 3939 | @xref{Register Classes}. There is thus not much flexibility in their |
| 3940 | definitions. |
| 3941 | |
| 3942 | @deffn {MD Expression} define_register_constraint name regclass docstring |
| 3943 | All three arguments are string constants. |
| 3944 | @var{name} is the name of the constraint, as it will appear in |
| 3945 | @code{match_operand} expressions. If @var{name} is a multi-letter |
| 3946 | constraint its length shall be the same for all constraints starting |
| 3947 | with the same letter. @var{regclass} can be either the |
| 3948 | name of the corresponding register class (@pxref{Register Classes}), |
| 3949 | or a C expression which evaluates to the appropriate register class. |
| 3950 | If it is an expression, it must have no side effects, and it cannot |
| 3951 | look at the operand. The usual use of expressions is to map some |
| 3952 | register constraints to @code{NO_REGS} when the register class |
| 3953 | is not available on a given subarchitecture. |
| 3954 | |
| 3955 | @var{docstring} is a sentence documenting the meaning of the |
| 3956 | constraint. Docstrings are explained further below. |
| 3957 | @end deffn |
| 3958 | |
| 3959 | Non-register constraints are more like predicates: the constraint |
| 3960 | definition gives a Boolean expression which indicates whether the |
| 3961 | constraint matches. |
| 3962 | |
| 3963 | @deffn {MD Expression} define_constraint name docstring exp |
| 3964 | The @var{name} and @var{docstring} arguments are the same as for |
| 3965 | @code{define_register_constraint}, but note that the docstring comes |
| 3966 | immediately after the name for these expressions. @var{exp} is an RTL |
| 3967 | expression, obeying the same rules as the RTL expressions in predicate |
| 3968 | definitions. @xref{Defining Predicates}, for details. If it |
| 3969 | evaluates true, the constraint matches; if it evaluates false, it |
| 3970 | doesn't. Constraint expressions should indicate which RTL codes they |
| 3971 | might match, just like predicate expressions. |
| 3972 | |
| 3973 | @code{match_test} C expressions have access to the |
| 3974 | following variables: |
| 3975 | |
| 3976 | @table @var |
| 3977 | @item op |
| 3978 | The RTL object defining the operand. |
| 3979 | @item mode |
| 3980 | The machine mode of @var{op}. |
| 3981 | @item ival |
| 3982 | @samp{INTVAL (@var{op})}, if @var{op} is a @code{const_int}. |
| 3983 | @item hval |
| 3984 | @samp{CONST_DOUBLE_HIGH (@var{op})}, if @var{op} is an integer |
| 3985 | @code{const_double}. |
| 3986 | @item lval |
| 3987 | @samp{CONST_DOUBLE_LOW (@var{op})}, if @var{op} is an integer |
| 3988 | @code{const_double}. |
| 3989 | @item rval |
| 3990 | @samp{CONST_DOUBLE_REAL_VALUE (@var{op})}, if @var{op} is a floating-point |
| 3991 | @code{const_double}. |
| 3992 | @end table |
| 3993 | |
| 3994 | The @var{*val} variables should only be used once another piece of the |
| 3995 | expression has verified that @var{op} is the appropriate kind of RTL |
| 3996 | object. |
| 3997 | @end deffn |
| 3998 | |
| 3999 | Most non-register constraints should be defined with |
| 4000 | @code{define_constraint}. The remaining two definition expressions |
| 4001 | are only appropriate for constraints that should be handled specially |
| 4002 | by @code{reload} if they fail to match. |
| 4003 | |
| 4004 | @deffn {MD Expression} define_memory_constraint name docstring exp |
| 4005 | Use this expression for constraints that match a subset of all memory |
| 4006 | operands: that is, @code{reload} can make them match by converting the |
| 4007 | operand to the form @samp{@w{(mem (reg @var{X}))}}, where @var{X} is a |
| 4008 | base register (from the register class specified by |
| 4009 | @code{BASE_REG_CLASS}, @pxref{Register Classes}). |
| 4010 | |
| 4011 | For example, on the S/390, some instructions do not accept arbitrary |
| 4012 | memory references, but only those that do not make use of an index |
| 4013 | register. The constraint letter @samp{Q} is defined to represent a |
| 4014 | memory address of this type. If @samp{Q} is defined with |
| 4015 | @code{define_memory_constraint}, a @samp{Q} constraint can handle any |
| 4016 | memory operand, because @code{reload} knows it can simply copy the |
| 4017 | memory address into a base register if required. This is analogous to |
| 4018 | the way an @samp{o} constraint can handle any memory operand. |
| 4019 | |
| 4020 | The syntax and semantics are otherwise identical to |
| 4021 | @code{define_constraint}. |
| 4022 | @end deffn |
| 4023 | |
| 4024 | @deffn {MD Expression} define_address_constraint name docstring exp |
| 4025 | Use this expression for constraints that match a subset of all address |
| 4026 | operands: that is, @code{reload} can make the constraint match by |
| 4027 | converting the operand to the form @samp{@w{(reg @var{X})}}, again |
| 4028 | with @var{X} a base register. |
| 4029 | |
| 4030 | Constraints defined with @code{define_address_constraint} can only be |
| 4031 | used with the @code{address_operand} predicate, or machine-specific |
| 4032 | predicates that work the same way. They are treated analogously to |
| 4033 | the generic @samp{p} constraint. |
| 4034 | |
| 4035 | The syntax and semantics are otherwise identical to |
| 4036 | @code{define_constraint}. |
| 4037 | @end deffn |
| 4038 | |
| 4039 | For historical reasons, names beginning with the letters @samp{G H} |
| 4040 | are reserved for constraints that match only @code{const_double}s, and |
| 4041 | names beginning with the letters @samp{I J K L M N O P} are reserved |
| 4042 | for constraints that match only @code{const_int}s. This may change in |
| 4043 | the future. For the time being, constraints with these names must be |
| 4044 | written in a stylized form, so that @code{genpreds} can tell you did |
| 4045 | it correctly: |
| 4046 | |
| 4047 | @smallexample |
| 4048 | @group |
| 4049 | (define_constraint "[@var{GHIJKLMNOP}]@dots{}" |
| 4050 | "@var{doc}@dots{}" |
| 4051 | (and (match_code "const_int") ; @r{@code{const_double} for G/H} |
| 4052 | @var{condition}@dots{})) ; @r{usually a @code{match_test}} |
| 4053 | @end group |
| 4054 | @end smallexample |
| 4055 | @c the semicolons line up in the formatted manual |
| 4056 | |
| 4057 | It is fine to use names beginning with other letters for constraints |
| 4058 | that match @code{const_double}s or @code{const_int}s. |
| 4059 | |
| 4060 | Each docstring in a constraint definition should be one or more complete |
| 4061 | sentences, marked up in Texinfo format. @emph{They are currently unused.} |
| 4062 | In the future they will be copied into the GCC manual, in @ref{Machine |
| 4063 | Constraints}, replacing the hand-maintained tables currently found in |
| 4064 | that section. Also, in the future the compiler may use this to give |
| 4065 | more helpful diagnostics when poor choice of @code{asm} constraints |
| 4066 | causes a reload failure. |
| 4067 | |
| 4068 | If you put the pseudo-Texinfo directive @samp{@@internal} at the |
| 4069 | beginning of a docstring, then (in the future) it will appear only in |
| 4070 | the internals manual's version of the machine-specific constraint tables. |
| 4071 | Use this for constraints that should not appear in @code{asm} statements. |
| 4072 | |
| 4073 | @node C Constraint Interface |
| 4074 | @subsection Testing constraints from C |
| 4075 | @cindex testing constraints |
| 4076 | @cindex constraints, testing |
| 4077 | |
| 4078 | It is occasionally useful to test a constraint from C code rather than |
| 4079 | implicitly via the constraint string in a @code{match_operand}. The |
| 4080 | generated file @file{tm_p.h} declares a few interfaces for working |
| 4081 | with machine-specific constraints. None of these interfaces work with |
| 4082 | the generic constraints described in @ref{Simple Constraints}. This |
| 4083 | may change in the future. |
| 4084 | |
| 4085 | @strong{Warning:} @file{tm_p.h} may declare other functions that |
| 4086 | operate on constraints, besides the ones documented here. Do not use |
| 4087 | those functions from machine-dependent code. They exist to implement |
| 4088 | the old constraint interface that machine-independent components of |
| 4089 | the compiler still expect. They will change or disappear in the |
| 4090 | future. |
| 4091 | |
| 4092 | Some valid constraint names are not valid C identifiers, so there is a |
| 4093 | mangling scheme for referring to them from C@. Constraint names that |
| 4094 | do not contain angle brackets or underscores are left unchanged. |
| 4095 | Underscores are doubled, each @samp{<} is replaced with @samp{_l}, and |
| 4096 | each @samp{>} with @samp{_g}. Here are some examples: |
| 4097 | |
| 4098 | @c the @c's prevent double blank lines in the printed manual. |
| 4099 | @example |
| 4100 | @multitable {Original} {Mangled} |
| 4101 | @item @strong{Original} @tab @strong{Mangled} @c |
| 4102 | @item @code{x} @tab @code{x} @c |
| 4103 | @item @code{P42x} @tab @code{P42x} @c |
| 4104 | @item @code{P4_x} @tab @code{P4__x} @c |
| 4105 | @item @code{P4>x} @tab @code{P4_gx} @c |
| 4106 | @item @code{P4>>} @tab @code{P4_g_g} @c |
| 4107 | @item @code{P4_g>} @tab @code{P4__g_g} @c |
| 4108 | @end multitable |
| 4109 | @end example |
| 4110 | |
| 4111 | Throughout this section, the variable @var{c} is either a constraint |
| 4112 | in the abstract sense, or a constant from @code{enum constraint_num}; |
| 4113 | the variable @var{m} is a mangled constraint name (usually as part of |
| 4114 | a larger identifier). |
| 4115 | |
| 4116 | @deftp Enum constraint_num |
| 4117 | For each machine-specific constraint, there is a corresponding |
| 4118 | enumeration constant: @samp{CONSTRAINT_} plus the mangled name of the |
| 4119 | constraint. Functions that take an @code{enum constraint_num} as an |
| 4120 | argument expect one of these constants. |
| 4121 | |
| 4122 | Machine-independent constraints do not have associated constants. |
| 4123 | This may change in the future. |
| 4124 | @end deftp |
| 4125 | |
| 4126 | @deftypefun {inline bool} satisfies_constraint_@var{m} (rtx @var{exp}) |
| 4127 | For each machine-specific, non-register constraint @var{m}, there is |
| 4128 | one of these functions; it returns @code{true} if @var{exp} satisfies the |
| 4129 | constraint. These functions are only visible if @file{rtl.h} was included |
| 4130 | before @file{tm_p.h}. |
| 4131 | @end deftypefun |
| 4132 | |
| 4133 | @deftypefun bool constraint_satisfied_p (rtx @var{exp}, enum constraint_num @var{c}) |
| 4134 | Like the @code{satisfies_constraint_@var{m}} functions, but the |
| 4135 | constraint to test is given as an argument, @var{c}. If @var{c} |
| 4136 | specifies a register constraint, this function will always return |
| 4137 | @code{false}. |
| 4138 | @end deftypefun |
| 4139 | |
| 4140 | @deftypefun {enum reg_class} regclass_for_constraint (enum constraint_num @var{c}) |
| 4141 | Returns the register class associated with @var{c}. If @var{c} is not |
| 4142 | a register constraint, or those registers are not available for the |
| 4143 | currently selected subtarget, returns @code{NO_REGS}. |
| 4144 | @end deftypefun |
| 4145 | |
| 4146 | Here is an example use of @code{satisfies_constraint_@var{m}}. In |
| 4147 | peephole optimizations (@pxref{Peephole Definitions}), operand |
| 4148 | constraint strings are ignored, so if there are relevant constraints, |
| 4149 | they must be tested in the C condition. In the example, the |
| 4150 | optimization is applied if operand 2 does @emph{not} satisfy the |
| 4151 | @samp{K} constraint. (This is a simplified version of a peephole |
| 4152 | definition from the i386 machine description.) |
| 4153 | |
| 4154 | @smallexample |
| 4155 | (define_peephole2 |
| 4156 | [(match_scratch:SI 3 "r") |
| 4157 | (set (match_operand:SI 0 "register_operand" "") |
| 4158 | (mult:SI (match_operand:SI 1 "memory_operand" "") |
| 4159 | (match_operand:SI 2 "immediate_operand" "")))] |
| 4160 | |
| 4161 | "!satisfies_constraint_K (operands[2])" |
| 4162 | |
| 4163 | [(set (match_dup 3) (match_dup 1)) |
| 4164 | (set (match_dup 0) (mult:SI (match_dup 3) (match_dup 2)))] |
| 4165 | |
| 4166 | "") |
| 4167 | @end smallexample |
| 4168 | |
| 4169 | @node Standard Names |
| 4170 | @section Standard Pattern Names For Generation |
| 4171 | @cindex standard pattern names |
| 4172 | @cindex pattern names |
| 4173 | @cindex names, pattern |
| 4174 | |
| 4175 | Here is a table of the instruction names that are meaningful in the RTL |
| 4176 | generation pass of the compiler. Giving one of these names to an |
| 4177 | instruction pattern tells the RTL generation pass that it can use the |
| 4178 | pattern to accomplish a certain task. |
| 4179 | |
| 4180 | @table @asis |
| 4181 | @cindex @code{mov@var{m}} instruction pattern |
| 4182 | @item @samp{mov@var{m}} |
| 4183 | Here @var{m} stands for a two-letter machine mode name, in lowercase. |
| 4184 | This instruction pattern moves data with that machine mode from operand |
| 4185 | 1 to operand 0. For example, @samp{movsi} moves full-word data. |
| 4186 | |
| 4187 | If operand 0 is a @code{subreg} with mode @var{m} of a register whose |
| 4188 | own mode is wider than @var{m}, the effect of this instruction is |
| 4189 | to store the specified value in the part of the register that corresponds |
| 4190 | to mode @var{m}. Bits outside of @var{m}, but which are within the |
| 4191 | same target word as the @code{subreg} are undefined. Bits which are |
| 4192 | outside the target word are left unchanged. |
| 4193 | |
| 4194 | This class of patterns is special in several ways. First of all, each |
| 4195 | of these names up to and including full word size @emph{must} be defined, |
| 4196 | because there is no other way to copy a datum from one place to another. |
| 4197 | If there are patterns accepting operands in larger modes, |
| 4198 | @samp{mov@var{m}} must be defined for integer modes of those sizes. |
| 4199 | |
| 4200 | Second, these patterns are not used solely in the RTL generation pass. |
| 4201 | Even the reload pass can generate move insns to copy values from stack |
| 4202 | slots into temporary registers. When it does so, one of the operands is |
| 4203 | a hard register and the other is an operand that can need to be reloaded |
| 4204 | into a register. |
| 4205 | |
| 4206 | @findex force_reg |
| 4207 | Therefore, when given such a pair of operands, the pattern must generate |
| 4208 | RTL which needs no reloading and needs no temporary registers---no |
| 4209 | registers other than the operands. For example, if you support the |
| 4210 | pattern with a @code{define_expand}, then in such a case the |
| 4211 | @code{define_expand} mustn't call @code{force_reg} or any other such |
| 4212 | function which might generate new pseudo registers. |
| 4213 | |
| 4214 | This requirement exists even for subword modes on a RISC machine where |
| 4215 | fetching those modes from memory normally requires several insns and |
| 4216 | some temporary registers. |
| 4217 | |
| 4218 | @findex change_address |
| 4219 | During reload a memory reference with an invalid address may be passed |
| 4220 | as an operand. Such an address will be replaced with a valid address |
| 4221 | later in the reload pass. In this case, nothing may be done with the |
| 4222 | address except to use it as it stands. If it is copied, it will not be |
| 4223 | replaced with a valid address. No attempt should be made to make such |
| 4224 | an address into a valid address and no routine (such as |
| 4225 | @code{change_address}) that will do so may be called. Note that |
| 4226 | @code{general_operand} will fail when applied to such an address. |
| 4227 | |
| 4228 | @findex reload_in_progress |
| 4229 | The global variable @code{reload_in_progress} (which must be explicitly |
| 4230 | declared if required) can be used to determine whether such special |
| 4231 | handling is required. |
| 4232 | |
| 4233 | The variety of operands that have reloads depends on the rest of the |
| 4234 | machine description, but typically on a RISC machine these can only be |
| 4235 | pseudo registers that did not get hard registers, while on other |
| 4236 | machines explicit memory references will get optional reloads. |
| 4237 | |
| 4238 | If a scratch register is required to move an object to or from memory, |
| 4239 | it can be allocated using @code{gen_reg_rtx} prior to life analysis. |
| 4240 | |
| 4241 | If there are cases which need scratch registers during or after reload, |
| 4242 | you must provide an appropriate secondary_reload target hook. |
| 4243 | |
| 4244 | @findex can_create_pseudo_p |
| 4245 | The macro @code{can_create_pseudo_p} can be used to determine if it |
| 4246 | is unsafe to create new pseudo registers. If this variable is nonzero, then |
| 4247 | it is unsafe to call @code{gen_reg_rtx} to allocate a new pseudo. |
| 4248 | |
| 4249 | The constraints on a @samp{mov@var{m}} must permit moving any hard |
| 4250 | register to any other hard register provided that |
| 4251 | @code{HARD_REGNO_MODE_OK} permits mode @var{m} in both registers and |
| 4252 | @code{TARGET_REGISTER_MOVE_COST} applied to their classes returns a value |
| 4253 | of 2. |
| 4254 | |
| 4255 | It is obligatory to support floating point @samp{mov@var{m}} |
| 4256 | instructions into and out of any registers that can hold fixed point |
| 4257 | values, because unions and structures (which have modes @code{SImode} or |
| 4258 | @code{DImode}) can be in those registers and they may have floating |
| 4259 | point members. |
| 4260 | |
| 4261 | There may also be a need to support fixed point @samp{mov@var{m}} |
| 4262 | instructions in and out of floating point registers. Unfortunately, I |
| 4263 | have forgotten why this was so, and I don't know whether it is still |
| 4264 | true. If @code{HARD_REGNO_MODE_OK} rejects fixed point values in |
| 4265 | floating point registers, then the constraints of the fixed point |
| 4266 | @samp{mov@var{m}} instructions must be designed to avoid ever trying to |
| 4267 | reload into a floating point register. |
| 4268 | |
| 4269 | @cindex @code{reload_in} instruction pattern |
| 4270 | @cindex @code{reload_out} instruction pattern |
| 4271 | @item @samp{reload_in@var{m}} |
| 4272 | @itemx @samp{reload_out@var{m}} |
| 4273 | These named patterns have been obsoleted by the target hook |
| 4274 | @code{secondary_reload}. |
| 4275 | |
| 4276 | Like @samp{mov@var{m}}, but used when a scratch register is required to |
| 4277 | move between operand 0 and operand 1. Operand 2 describes the scratch |
| 4278 | register. See the discussion of the @code{SECONDARY_RELOAD_CLASS} |
| 4279 | macro in @pxref{Register Classes}. |
| 4280 | |
| 4281 | There are special restrictions on the form of the @code{match_operand}s |
| 4282 | used in these patterns. First, only the predicate for the reload |
| 4283 | operand is examined, i.e., @code{reload_in} examines operand 1, but not |
| 4284 | the predicates for operand 0 or 2. Second, there may be only one |
| 4285 | alternative in the constraints. Third, only a single register class |
| 4286 | letter may be used for the constraint; subsequent constraint letters |
| 4287 | are ignored. As a special exception, an empty constraint string |
| 4288 | matches the @code{ALL_REGS} register class. This may relieve ports |
| 4289 | of the burden of defining an @code{ALL_REGS} constraint letter just |
| 4290 | for these patterns. |
| 4291 | |
| 4292 | @cindex @code{movstrict@var{m}} instruction pattern |
| 4293 | @item @samp{movstrict@var{m}} |
| 4294 | Like @samp{mov@var{m}} except that if operand 0 is a @code{subreg} |
| 4295 | with mode @var{m} of a register whose natural mode is wider, |
| 4296 | the @samp{movstrict@var{m}} instruction is guaranteed not to alter |
| 4297 | any of the register except the part which belongs to mode @var{m}. |
| 4298 | |
| 4299 | @cindex @code{movmisalign@var{m}} instruction pattern |
| 4300 | @item @samp{movmisalign@var{m}} |
| 4301 | This variant of a move pattern is designed to load or store a value |
| 4302 | from a memory address that is not naturally aligned for its mode. |
| 4303 | For a store, the memory will be in operand 0; for a load, the memory |
| 4304 | will be in operand 1. The other operand is guaranteed not to be a |
| 4305 | memory, so that it's easy to tell whether this is a load or store. |
| 4306 | |
| 4307 | This pattern is used by the autovectorizer, and when expanding a |
| 4308 | @code{MISALIGNED_INDIRECT_REF} expression. |
| 4309 | |
| 4310 | @cindex @code{load_multiple} instruction pattern |
| 4311 | @item @samp{load_multiple} |
| 4312 | Load several consecutive memory locations into consecutive registers. |
| 4313 | Operand 0 is the first of the consecutive registers, operand 1 |
| 4314 | is the first memory location, and operand 2 is a constant: the |
| 4315 | number of consecutive registers. |
| 4316 | |
| 4317 | Define this only if the target machine really has such an instruction; |
| 4318 | do not define this if the most efficient way of loading consecutive |
| 4319 | registers from memory is to do them one at a time. |
| 4320 | |
| 4321 | On some machines, there are restrictions as to which consecutive |
| 4322 | registers can be stored into memory, such as particular starting or |
| 4323 | ending register numbers or only a range of valid counts. For those |
| 4324 | machines, use a @code{define_expand} (@pxref{Expander Definitions}) |
| 4325 | and make the pattern fail if the restrictions are not met. |
| 4326 | |
| 4327 | Write the generated insn as a @code{parallel} with elements being a |
| 4328 | @code{set} of one register from the appropriate memory location (you may |
| 4329 | also need @code{use} or @code{clobber} elements). Use a |
| 4330 | @code{match_parallel} (@pxref{RTL Template}) to recognize the insn. See |
| 4331 | @file{rs6000.md} for examples of the use of this insn pattern. |
| 4332 | |
| 4333 | @cindex @samp{store_multiple} instruction pattern |
| 4334 | @item @samp{store_multiple} |
| 4335 | Similar to @samp{load_multiple}, but store several consecutive registers |
| 4336 | into consecutive memory locations. Operand 0 is the first of the |
| 4337 | consecutive memory locations, operand 1 is the first register, and |
| 4338 | operand 2 is a constant: the number of consecutive registers. |
| 4339 | |
| 4340 | @cindex @code{vec_load_lanes@var{m}@var{n}} instruction pattern |
| 4341 | @item @samp{vec_load_lanes@var{m}@var{n}} |
| 4342 | Perform an interleaved load of several vectors from memory operand 1 |
| 4343 | into register operand 0. Both operands have mode @var{m}. The register |
| 4344 | operand is viewed as holding consecutive vectors of mode @var{n}, |
| 4345 | while the memory operand is a flat array that contains the same number |
| 4346 | of elements. The operation is equivalent to: |
| 4347 | |
| 4348 | @smallexample |
| 4349 | int c = GET_MODE_SIZE (@var{m}) / GET_MODE_SIZE (@var{n}); |
| 4350 | for (j = 0; j < GET_MODE_NUNITS (@var{n}); j++) |
| 4351 | for (i = 0; i < c; i++) |
| 4352 | operand0[i][j] = operand1[j * c + i]; |
| 4353 | @end smallexample |
| 4354 | |
| 4355 | For example, @samp{vec_load_lanestiv4hi} loads 8 16-bit values |
| 4356 | from memory into a register of mode @samp{TI}@. The register |
| 4357 | contains two consecutive vectors of mode @samp{V4HI}@. |
| 4358 | |
| 4359 | This pattern can only be used if: |
| 4360 | @smallexample |
| 4361 | TARGET_ARRAY_MODE_SUPPORTED_P (@var{n}, @var{c}) |
| 4362 | @end smallexample |
| 4363 | is true. GCC assumes that, if a target supports this kind of |
| 4364 | instruction for some mode @var{n}, it also supports unaligned |
| 4365 | loads for vectors of mode @var{n}. |
| 4366 | |
| 4367 | @cindex @code{vec_store_lanes@var{m}@var{n}} instruction pattern |
| 4368 | @item @samp{vec_store_lanes@var{m}@var{n}} |
| 4369 | Equivalent to @samp{vec_load_lanes@var{m}@var{n}}, with the memory |
| 4370 | and register operands reversed. That is, the instruction is |
| 4371 | equivalent to: |
| 4372 | |
| 4373 | @smallexample |
| 4374 | int c = GET_MODE_SIZE (@var{m}) / GET_MODE_SIZE (@var{n}); |
| 4375 | for (j = 0; j < GET_MODE_NUNITS (@var{n}); j++) |
| 4376 | for (i = 0; i < c; i++) |
| 4377 | operand0[j * c + i] = operand1[i][j]; |
| 4378 | @end smallexample |
| 4379 | |
| 4380 | for a memory operand 0 and register operand 1. |
| 4381 | |
| 4382 | @cindex @code{vec_set@var{m}} instruction pattern |
| 4383 | @item @samp{vec_set@var{m}} |
| 4384 | Set given field in the vector value. Operand 0 is the vector to modify, |
| 4385 | operand 1 is new value of field and operand 2 specify the field index. |
| 4386 | |
| 4387 | @cindex @code{vec_extract@var{m}} instruction pattern |
| 4388 | @item @samp{vec_extract@var{m}} |
| 4389 | Extract given field from the vector value. Operand 1 is the vector, operand 2 |
| 4390 | specify field index and operand 0 place to store value into. |
| 4391 | |
| 4392 | @cindex @code{vec_init@var{m}} instruction pattern |
| 4393 | @item @samp{vec_init@var{m}} |
| 4394 | Initialize the vector to given values. Operand 0 is the vector to initialize |
| 4395 | and operand 1 is parallel containing values for individual fields. |
| 4396 | |
| 4397 | @cindex @code{vcond@var{m}@var{n}} instruction pattern |
| 4398 | @item @samp{vcond@var{m}@var{n}} |
| 4399 | Output a conditional vector move. Operand 0 is the destination to |
| 4400 | receive a combination of operand 1 and operand 2, which are of mode @var{m}, |
| 4401 | dependent on the outcome of the predicate in operand 3 which is a |
| 4402 | vector comparison with operands of mode @var{n} in operands 4 and 5. The |
| 4403 | modes @var{m} and @var{n} should have the same size. Operand 0 |
| 4404 | will be set to the value @var{op1} & @var{msk} | @var{op2} & ~@var{msk} |
| 4405 | where @var{msk} is computed by element-wise evaluation of the vector |
| 4406 | comparison with a truth value of all-ones and a false value of all-zeros. |
| 4407 | |
| 4408 | @cindex @code{vec_perm@var{m}} instruction pattern |
| 4409 | @item @samp{vec_perm@var{m}} |
| 4410 | Output a (variable) vector permutation. Operand 0 is the destination |
| 4411 | to receive elements from operand 1 and operand 2, which are of mode |
| 4412 | @var{m}. Operand 3 is the @dfn{selector}. It is an integral mode |
| 4413 | vector of the same width and number of elements as mode @var{m}. |
| 4414 | |
| 4415 | The input elements are numbered from 0 in operand 1 through |
| 4416 | @math{2*@var{N}-1} in operand 2. The elements of the selector must |
| 4417 | be computed modulo @math{2*@var{N}}. Note that if |
| 4418 | @code{rtx_equal_p(operand1, operand2)}, this can be implemented |
| 4419 | with just operand 1 and selector elements modulo @var{N}. |
| 4420 | |
| 4421 | In order to make things easy for a number of targets, if there is no |
| 4422 | @samp{vec_perm} pattern for mode @var{m}, but there is for mode @var{q} |
| 4423 | where @var{q} is a vector of @code{QImode} of the same width as @var{m}, |
| 4424 | the middle-end will lower the mode @var{m} @code{VEC_PERM_EXPR} to |
| 4425 | mode @var{q}. |
| 4426 | |
| 4427 | @cindex @code{vec_perm_const@var{m}} instruction pattern |
| 4428 | @item @samp{vec_perm_const@var{m}} |
| 4429 | Like @samp{vec_perm} except that the permutation is a compile-time |
| 4430 | constant. That is, operand 3, the @dfn{selector}, is a @code{CONST_VECTOR}. |
| 4431 | |
| 4432 | Some targets cannot perform a permutation with a variable selector, |
| 4433 | but can efficiently perform a constant permutation. Further, the |
| 4434 | target hook @code{vec_perm_ok} is queried to determine if the |
| 4435 | specific constant permutation is available efficiently; the named |
| 4436 | pattern is never expanded without @code{vec_perm_ok} returning true. |
| 4437 | |
| 4438 | There is no need for a target to supply both @samp{vec_perm@var{m}} |
| 4439 | and @samp{vec_perm_const@var{m}} if the former can trivially implement |
| 4440 | the operation with, say, the vector constant loaded into a register. |
| 4441 | |
| 4442 | @cindex @code{push@var{m}1} instruction pattern |
| 4443 | @item @samp{push@var{m}1} |
| 4444 | Output a push instruction. Operand 0 is value to push. Used only when |
| 4445 | @code{PUSH_ROUNDING} is defined. For historical reason, this pattern may be |
| 4446 | missing and in such case an @code{mov} expander is used instead, with a |
| 4447 | @code{MEM} expression forming the push operation. The @code{mov} expander |
| 4448 | method is deprecated. |
| 4449 | |
| 4450 | @cindex @code{add@var{m}3} instruction pattern |
| 4451 | @item @samp{add@var{m}3} |
| 4452 | Add operand 2 and operand 1, storing the result in operand 0. All operands |
| 4453 | must have mode @var{m}. This can be used even on two-address machines, by |
| 4454 | means of constraints requiring operands 1 and 0 to be the same location. |
| 4455 | |
| 4456 | @cindex @code{ssadd@var{m}3} instruction pattern |
| 4457 | @cindex @code{usadd@var{m}3} instruction pattern |
| 4458 | @cindex @code{sub@var{m}3} instruction pattern |
| 4459 | @cindex @code{sssub@var{m}3} instruction pattern |
| 4460 | @cindex @code{ussub@var{m}3} instruction pattern |
| 4461 | @cindex @code{mul@var{m}3} instruction pattern |
| 4462 | @cindex @code{ssmul@var{m}3} instruction pattern |
| 4463 | @cindex @code{usmul@var{m}3} instruction pattern |
| 4464 | @cindex @code{div@var{m}3} instruction pattern |
| 4465 | @cindex @code{ssdiv@var{m}3} instruction pattern |
| 4466 | @cindex @code{udiv@var{m}3} instruction pattern |
| 4467 | @cindex @code{usdiv@var{m}3} instruction pattern |
| 4468 | @cindex @code{mod@var{m}3} instruction pattern |
| 4469 | @cindex @code{umod@var{m}3} instruction pattern |
| 4470 | @cindex @code{umin@var{m}3} instruction pattern |
| 4471 | @cindex @code{umax@var{m}3} instruction pattern |
| 4472 | @cindex @code{and@var{m}3} instruction pattern |
| 4473 | @cindex @code{ior@var{m}3} instruction pattern |
| 4474 | @cindex @code{xor@var{m}3} instruction pattern |
| 4475 | @item @samp{ssadd@var{m}3}, @samp{usadd@var{m}3} |
| 4476 | @item @samp{sub@var{m}3}, @samp{sssub@var{m}3}, @samp{ussub@var{m}3} |
| 4477 | @item @samp{mul@var{m}3}, @samp{ssmul@var{m}3}, @samp{usmul@var{m}3} |
| 4478 | @itemx @samp{div@var{m}3}, @samp{ssdiv@var{m}3} |
| 4479 | @itemx @samp{udiv@var{m}3}, @samp{usdiv@var{m}3} |
| 4480 | @itemx @samp{mod@var{m}3}, @samp{umod@var{m}3} |
| 4481 | @itemx @samp{umin@var{m}3}, @samp{umax@var{m}3} |
| 4482 | @itemx @samp{and@var{m}3}, @samp{ior@var{m}3}, @samp{xor@var{m}3} |
| 4483 | Similar, for other arithmetic operations. |
| 4484 | |
| 4485 | @cindex @code{fma@var{m}4} instruction pattern |
| 4486 | @item @samp{fma@var{m}4} |
| 4487 | Multiply operand 2 and operand 1, then add operand 3, storing the |
| 4488 | result in operand 0 without doing an intermediate rounding step. All |
| 4489 | operands must have mode @var{m}. This pattern is used to implement |
| 4490 | the @code{fma}, @code{fmaf}, and @code{fmal} builtin functions from |
| 4491 | the ISO C99 standard. |
| 4492 | |
| 4493 | @cindex @code{fms@var{m}4} instruction pattern |
| 4494 | @item @samp{fms@var{m}4} |
| 4495 | Like @code{fma@var{m}4}, except operand 3 subtracted from the |
| 4496 | product instead of added to the product. This is represented |
| 4497 | in the rtl as |
| 4498 | |
| 4499 | @smallexample |
| 4500 | (fma:@var{m} @var{op1} @var{op2} (neg:@var{m} @var{op3})) |
| 4501 | @end smallexample |
| 4502 | |
| 4503 | @cindex @code{fnma@var{m}4} instruction pattern |
| 4504 | @item @samp{fnma@var{m}4} |
| 4505 | Like @code{fma@var{m}4} except that the intermediate product |
| 4506 | is negated before being added to operand 3. This is represented |
| 4507 | in the rtl as |
| 4508 | |
| 4509 | @smallexample |
| 4510 | (fma:@var{m} (neg:@var{m} @var{op1}) @var{op2} @var{op3}) |
| 4511 | @end smallexample |
| 4512 | |
| 4513 | @cindex @code{fnms@var{m}4} instruction pattern |
| 4514 | @item @samp{fnms@var{m}4} |
| 4515 | Like @code{fms@var{m}4} except that the intermediate product |
| 4516 | is negated before subtracting operand 3. This is represented |
| 4517 | in the rtl as |
| 4518 | |
| 4519 | @smallexample |
| 4520 | (fma:@var{m} (neg:@var{m} @var{op1}) @var{op2} (neg:@var{m} @var{op3})) |
| 4521 | @end smallexample |
| 4522 | |
| 4523 | @cindex @code{min@var{m}3} instruction pattern |
| 4524 | @cindex @code{max@var{m}3} instruction pattern |
| 4525 | @item @samp{smin@var{m}3}, @samp{smax@var{m}3} |
| 4526 | Signed minimum and maximum operations. When used with floating point, |
| 4527 | if both operands are zeros, or if either operand is @code{NaN}, then |
| 4528 | it is unspecified which of the two operands is returned as the result. |
| 4529 | |
| 4530 | @cindex @code{reduc_smin_@var{m}} instruction pattern |
| 4531 | @cindex @code{reduc_smax_@var{m}} instruction pattern |
| 4532 | @item @samp{reduc_smin_@var{m}}, @samp{reduc_smax_@var{m}} |
| 4533 | Find the signed minimum/maximum of the elements of a vector. The vector is |
| 4534 | operand 1, and the scalar result is stored in the least significant bits of |
| 4535 | operand 0 (also a vector). The output and input vector should have the same |
| 4536 | modes. |
| 4537 | |
| 4538 | @cindex @code{reduc_umin_@var{m}} instruction pattern |
| 4539 | @cindex @code{reduc_umax_@var{m}} instruction pattern |
| 4540 | @item @samp{reduc_umin_@var{m}}, @samp{reduc_umax_@var{m}} |
| 4541 | Find the unsigned minimum/maximum of the elements of a vector. The vector is |
| 4542 | operand 1, and the scalar result is stored in the least significant bits of |
| 4543 | operand 0 (also a vector). The output and input vector should have the same |
| 4544 | modes. |
| 4545 | |
| 4546 | @cindex @code{reduc_splus_@var{m}} instruction pattern |
| 4547 | @item @samp{reduc_splus_@var{m}} |
| 4548 | Compute the sum of the signed elements of a vector. The vector is operand 1, |
| 4549 | and the scalar result is stored in the least significant bits of operand 0 |
| 4550 | (also a vector). The output and input vector should have the same modes. |
| 4551 | |
| 4552 | @cindex @code{reduc_uplus_@var{m}} instruction pattern |
| 4553 | @item @samp{reduc_uplus_@var{m}} |
| 4554 | Compute the sum of the unsigned elements of a vector. The vector is operand 1, |
| 4555 | and the scalar result is stored in the least significant bits of operand 0 |
| 4556 | (also a vector). The output and input vector should have the same modes. |
| 4557 | |
| 4558 | @cindex @code{sdot_prod@var{m}} instruction pattern |
| 4559 | @item @samp{sdot_prod@var{m}} |
| 4560 | @cindex @code{udot_prod@var{m}} instruction pattern |
| 4561 | @item @samp{udot_prod@var{m}} |
| 4562 | Compute the sum of the products of two signed/unsigned elements. |
| 4563 | Operand 1 and operand 2 are of the same mode. Their product, which is of a |
| 4564 | wider mode, is computed and added to operand 3. Operand 3 is of a mode equal or |
| 4565 | wider than the mode of the product. The result is placed in operand 0, which |
| 4566 | is of the same mode as operand 3. |
| 4567 | |
| 4568 | @cindex @code{ssum_widen@var{m3}} instruction pattern |
| 4569 | @item @samp{ssum_widen@var{m3}} |
| 4570 | @cindex @code{usum_widen@var{m3}} instruction pattern |
| 4571 | @item @samp{usum_widen@var{m3}} |
| 4572 | Operands 0 and 2 are of the same mode, which is wider than the mode of |
| 4573 | operand 1. Add operand 1 to operand 2 and place the widened result in |
| 4574 | operand 0. (This is used express accumulation of elements into an accumulator |
| 4575 | of a wider mode.) |
| 4576 | |
| 4577 | @cindex @code{vec_shl_@var{m}} instruction pattern |
| 4578 | @cindex @code{vec_shr_@var{m}} instruction pattern |
| 4579 | @item @samp{vec_shl_@var{m}}, @samp{vec_shr_@var{m}} |
| 4580 | Whole vector left/right shift in bits. |
| 4581 | Operand 1 is a vector to be shifted. |
| 4582 | Operand 2 is an integer shift amount in bits. |
| 4583 | Operand 0 is where the resulting shifted vector is stored. |
| 4584 | The output and input vectors should have the same modes. |
| 4585 | |
| 4586 | @cindex @code{vec_pack_trunc_@var{m}} instruction pattern |
| 4587 | @item @samp{vec_pack_trunc_@var{m}} |
| 4588 | Narrow (demote) and merge the elements of two vectors. Operands 1 and 2 |
| 4589 | are vectors of the same mode having N integral or floating point elements |
| 4590 | of size S@. Operand 0 is the resulting vector in which 2*N elements of |
| 4591 | size N/2 are concatenated after narrowing them down using truncation. |
| 4592 | |
| 4593 | @cindex @code{vec_pack_ssat_@var{m}} instruction pattern |
| 4594 | @cindex @code{vec_pack_usat_@var{m}} instruction pattern |
| 4595 | @item @samp{vec_pack_ssat_@var{m}}, @samp{vec_pack_usat_@var{m}} |
| 4596 | Narrow (demote) and merge the elements of two vectors. Operands 1 and 2 |
| 4597 | are vectors of the same mode having N integral elements of size S. |
| 4598 | Operand 0 is the resulting vector in which the elements of the two input |
| 4599 | vectors are concatenated after narrowing them down using signed/unsigned |
| 4600 | saturating arithmetic. |
| 4601 | |
| 4602 | @cindex @code{vec_pack_sfix_trunc_@var{m}} instruction pattern |
| 4603 | @cindex @code{vec_pack_ufix_trunc_@var{m}} instruction pattern |
| 4604 | @item @samp{vec_pack_sfix_trunc_@var{m}}, @samp{vec_pack_ufix_trunc_@var{m}} |
| 4605 | Narrow, convert to signed/unsigned integral type and merge the elements |
| 4606 | of two vectors. Operands 1 and 2 are vectors of the same mode having N |
| 4607 | floating point elements of size S@. Operand 0 is the resulting vector |
| 4608 | in which 2*N elements of size N/2 are concatenated. |
| 4609 | |
| 4610 | @cindex @code{vec_unpacks_hi_@var{m}} instruction pattern |
| 4611 | @cindex @code{vec_unpacks_lo_@var{m}} instruction pattern |
| 4612 | @item @samp{vec_unpacks_hi_@var{m}}, @samp{vec_unpacks_lo_@var{m}} |
| 4613 | Extract and widen (promote) the high/low part of a vector of signed |
| 4614 | integral or floating point elements. The input vector (operand 1) has N |
| 4615 | elements of size S@. Widen (promote) the high/low elements of the vector |
| 4616 | using signed or floating point extension and place the resulting N/2 |
| 4617 | values of size 2*S in the output vector (operand 0). |
| 4618 | |
| 4619 | @cindex @code{vec_unpacku_hi_@var{m}} instruction pattern |
| 4620 | @cindex @code{vec_unpacku_lo_@var{m}} instruction pattern |
| 4621 | @item @samp{vec_unpacku_hi_@var{m}}, @samp{vec_unpacku_lo_@var{m}} |
| 4622 | Extract and widen (promote) the high/low part of a vector of unsigned |
| 4623 | integral elements. The input vector (operand 1) has N elements of size S. |
| 4624 | Widen (promote) the high/low elements of the vector using zero extension and |
| 4625 | place the resulting N/2 values of size 2*S in the output vector (operand 0). |
| 4626 | |
| 4627 | @cindex @code{vec_unpacks_float_hi_@var{m}} instruction pattern |
| 4628 | @cindex @code{vec_unpacks_float_lo_@var{m}} instruction pattern |
| 4629 | @cindex @code{vec_unpacku_float_hi_@var{m}} instruction pattern |
| 4630 | @cindex @code{vec_unpacku_float_lo_@var{m}} instruction pattern |
| 4631 | @item @samp{vec_unpacks_float_hi_@var{m}}, @samp{vec_unpacks_float_lo_@var{m}} |
| 4632 | @itemx @samp{vec_unpacku_float_hi_@var{m}}, @samp{vec_unpacku_float_lo_@var{m}} |
| 4633 | Extract, convert to floating point type and widen the high/low part of a |
| 4634 | vector of signed/unsigned integral elements. The input vector (operand 1) |
| 4635 | has N elements of size S@. Convert the high/low elements of the vector using |
| 4636 | floating point conversion and place the resulting N/2 values of size 2*S in |
| 4637 | the output vector (operand 0). |
| 4638 | |
| 4639 | @cindex @code{vec_widen_umult_hi_@var{m}} instruction pattern |
| 4640 | @cindex @code{vec_widen_umult_lo_@var{m}} instruction pattern |
| 4641 | @cindex @code{vec_widen_smult_hi_@var{m}} instruction pattern |
| 4642 | @cindex @code{vec_widen_smult_lo_@var{m}} instruction pattern |
| 4643 | @cindex @code{vec_widen_umult_even_@var{m}} instruction pattern |
| 4644 | @cindex @code{vec_widen_umult_odd_@var{m}} instruction pattern |
| 4645 | @cindex @code{vec_widen_smult_even_@var{m}} instruction pattern |
| 4646 | @cindex @code{vec_widen_smult_odd_@var{m}} instruction pattern |
| 4647 | @item @samp{vec_widen_umult_hi_@var{m}}, @samp{vec_widen_umult_lo_@var{m}} |
| 4648 | @itemx @samp{vec_widen_smult_hi_@var{m}}, @samp{vec_widen_smult_lo_@var{m}} |
| 4649 | @itemx @samp{vec_widen_umult_even_@var{m}}, @samp{vec_widen_umult_odd_@var{m}} |
| 4650 | @itemx @samp{vec_widen_smult_even_@var{m}}, @samp{vec_widen_smult_odd_@var{m}} |
| 4651 | Signed/Unsigned widening multiplication. The two inputs (operands 1 and 2) |
| 4652 | are vectors with N signed/unsigned elements of size S@. Multiply the high/low |
| 4653 | or even/odd elements of the two vectors, and put the N/2 products of size 2*S |
| 4654 | in the output vector (operand 0). |
| 4655 | |
| 4656 | @cindex @code{vec_widen_ushiftl_hi_@var{m}} instruction pattern |
| 4657 | @cindex @code{vec_widen_ushiftl_lo_@var{m}} instruction pattern |
| 4658 | @cindex @code{vec_widen_sshiftl_hi_@var{m}} instruction pattern |
| 4659 | @cindex @code{vec_widen_sshiftl_lo_@var{m}} instruction pattern |
| 4660 | @item @samp{vec_widen_ushiftl_hi_@var{m}}, @samp{vec_widen_ushiftl_lo_@var{m}} |
| 4661 | @itemx @samp{vec_widen_sshiftl_hi_@var{m}}, @samp{vec_widen_sshiftl_lo_@var{m}} |
| 4662 | Signed/Unsigned widening shift left. The first input (operand 1) is a vector |
| 4663 | with N signed/unsigned elements of size S@. Operand 2 is a constant. Shift |
| 4664 | the high/low elements of operand 1, and put the N/2 results of size 2*S in the |
| 4665 | output vector (operand 0). |
| 4666 | |
| 4667 | @cindex @code{mulhisi3} instruction pattern |
| 4668 | @item @samp{mulhisi3} |
| 4669 | Multiply operands 1 and 2, which have mode @code{HImode}, and store |
| 4670 | a @code{SImode} product in operand 0. |
| 4671 | |
| 4672 | @cindex @code{mulqihi3} instruction pattern |
| 4673 | @cindex @code{mulsidi3} instruction pattern |
| 4674 | @item @samp{mulqihi3}, @samp{mulsidi3} |
| 4675 | Similar widening-multiplication instructions of other widths. |
| 4676 | |
| 4677 | @cindex @code{umulqihi3} instruction pattern |
| 4678 | @cindex @code{umulhisi3} instruction pattern |
| 4679 | @cindex @code{umulsidi3} instruction pattern |
| 4680 | @item @samp{umulqihi3}, @samp{umulhisi3}, @samp{umulsidi3} |
| 4681 | Similar widening-multiplication instructions that do unsigned |
| 4682 | multiplication. |
| 4683 | |
| 4684 | @cindex @code{usmulqihi3} instruction pattern |
| 4685 | @cindex @code{usmulhisi3} instruction pattern |
| 4686 | @cindex @code{usmulsidi3} instruction pattern |
| 4687 | @item @samp{usmulqihi3}, @samp{usmulhisi3}, @samp{usmulsidi3} |
| 4688 | Similar widening-multiplication instructions that interpret the first |
| 4689 | operand as unsigned and the second operand as signed, then do a signed |
| 4690 | multiplication. |
| 4691 | |
| 4692 | @cindex @code{smul@var{m}3_highpart} instruction pattern |
| 4693 | @item @samp{smul@var{m}3_highpart} |
| 4694 | Perform a signed multiplication of operands 1 and 2, which have mode |
| 4695 | @var{m}, and store the most significant half of the product in operand 0. |
| 4696 | The least significant half of the product is discarded. |
| 4697 | |
| 4698 | @cindex @code{umul@var{m}3_highpart} instruction pattern |
| 4699 | @item @samp{umul@var{m}3_highpart} |
| 4700 | Similar, but the multiplication is unsigned. |
| 4701 | |
| 4702 | @cindex @code{madd@var{m}@var{n}4} instruction pattern |
| 4703 | @item @samp{madd@var{m}@var{n}4} |
| 4704 | Multiply operands 1 and 2, sign-extend them to mode @var{n}, add |
| 4705 | operand 3, and store the result in operand 0. Operands 1 and 2 |
| 4706 | have mode @var{m} and operands 0 and 3 have mode @var{n}. |
| 4707 | Both modes must be integer or fixed-point modes and @var{n} must be twice |
| 4708 | the size of @var{m}. |
| 4709 | |
| 4710 | In other words, @code{madd@var{m}@var{n}4} is like |
| 4711 | @code{mul@var{m}@var{n}3} except that it also adds operand 3. |
| 4712 | |
| 4713 | These instructions are not allowed to @code{FAIL}. |
| 4714 | |
| 4715 | @cindex @code{umadd@var{m}@var{n}4} instruction pattern |
| 4716 | @item @samp{umadd@var{m}@var{n}4} |
| 4717 | Like @code{madd@var{m}@var{n}4}, but zero-extend the multiplication |
| 4718 | operands instead of sign-extending them. |
| 4719 | |
| 4720 | @cindex @code{ssmadd@var{m}@var{n}4} instruction pattern |
| 4721 | @item @samp{ssmadd@var{m}@var{n}4} |
| 4722 | Like @code{madd@var{m}@var{n}4}, but all involved operations must be |
| 4723 | signed-saturating. |
| 4724 | |
| 4725 | @cindex @code{usmadd@var{m}@var{n}4} instruction pattern |
| 4726 | @item @samp{usmadd@var{m}@var{n}4} |
| 4727 | Like @code{umadd@var{m}@var{n}4}, but all involved operations must be |
| 4728 | unsigned-saturating. |
| 4729 | |
| 4730 | @cindex @code{msub@var{m}@var{n}4} instruction pattern |
| 4731 | @item @samp{msub@var{m}@var{n}4} |
| 4732 | Multiply operands 1 and 2, sign-extend them to mode @var{n}, subtract the |
| 4733 | result from operand 3, and store the result in operand 0. Operands 1 and 2 |
| 4734 | have mode @var{m} and operands 0 and 3 have mode @var{n}. |
| 4735 | Both modes must be integer or fixed-point modes and @var{n} must be twice |
| 4736 | the size of @var{m}. |
| 4737 | |
| 4738 | In other words, @code{msub@var{m}@var{n}4} is like |
| 4739 | @code{mul@var{m}@var{n}3} except that it also subtracts the result |
| 4740 | from operand 3. |
| 4741 | |
| 4742 | These instructions are not allowed to @code{FAIL}. |
| 4743 | |
| 4744 | @cindex @code{umsub@var{m}@var{n}4} instruction pattern |
| 4745 | @item @samp{umsub@var{m}@var{n}4} |
| 4746 | Like @code{msub@var{m}@var{n}4}, but zero-extend the multiplication |
| 4747 | operands instead of sign-extending them. |
| 4748 | |
| 4749 | @cindex @code{ssmsub@var{m}@var{n}4} instruction pattern |
| 4750 | @item @samp{ssmsub@var{m}@var{n}4} |
| 4751 | Like @code{msub@var{m}@var{n}4}, but all involved operations must be |
| 4752 | signed-saturating. |
| 4753 | |
| 4754 | @cindex @code{usmsub@var{m}@var{n}4} instruction pattern |
| 4755 | @item @samp{usmsub@var{m}@var{n}4} |
| 4756 | Like @code{umsub@var{m}@var{n}4}, but all involved operations must be |
| 4757 | unsigned-saturating. |
| 4758 | |
| 4759 | @cindex @code{divmod@var{m}4} instruction pattern |
| 4760 | @item @samp{divmod@var{m}4} |
| 4761 | Signed division that produces both a quotient and a remainder. |
| 4762 | Operand 1 is divided by operand 2 to produce a quotient stored |
| 4763 | in operand 0 and a remainder stored in operand 3. |
| 4764 | |
| 4765 | For machines with an instruction that produces both a quotient and a |
| 4766 | remainder, provide a pattern for @samp{divmod@var{m}4} but do not |
| 4767 | provide patterns for @samp{div@var{m}3} and @samp{mod@var{m}3}. This |
| 4768 | allows optimization in the relatively common case when both the quotient |
| 4769 | and remainder are computed. |
| 4770 | |
| 4771 | If an instruction that just produces a quotient or just a remainder |
| 4772 | exists and is more efficient than the instruction that produces both, |
| 4773 | write the output routine of @samp{divmod@var{m}4} to call |
| 4774 | @code{find_reg_note} and look for a @code{REG_UNUSED} note on the |
| 4775 | quotient or remainder and generate the appropriate instruction. |
| 4776 | |
| 4777 | @cindex @code{udivmod@var{m}4} instruction pattern |
| 4778 | @item @samp{udivmod@var{m}4} |
| 4779 | Similar, but does unsigned division. |
| 4780 | |
| 4781 | @anchor{shift patterns} |
| 4782 | @cindex @code{ashl@var{m}3} instruction pattern |
| 4783 | @cindex @code{ssashl@var{m}3} instruction pattern |
| 4784 | @cindex @code{usashl@var{m}3} instruction pattern |
| 4785 | @item @samp{ashl@var{m}3}, @samp{ssashl@var{m}3}, @samp{usashl@var{m}3} |
| 4786 | Arithmetic-shift operand 1 left by a number of bits specified by operand |
| 4787 | 2, and store the result in operand 0. Here @var{m} is the mode of |
| 4788 | operand 0 and operand 1; operand 2's mode is specified by the |
| 4789 | instruction pattern, and the compiler will convert the operand to that |
| 4790 | mode before generating the instruction. The meaning of out-of-range shift |
| 4791 | counts can optionally be specified by @code{TARGET_SHIFT_TRUNCATION_MASK}. |
| 4792 | @xref{TARGET_SHIFT_TRUNCATION_MASK}. Operand 2 is always a scalar type. |
| 4793 | |
| 4794 | @cindex @code{ashr@var{m}3} instruction pattern |
| 4795 | @cindex @code{lshr@var{m}3} instruction pattern |
| 4796 | @cindex @code{rotl@var{m}3} instruction pattern |
| 4797 | @cindex @code{rotr@var{m}3} instruction pattern |
| 4798 | @item @samp{ashr@var{m}3}, @samp{lshr@var{m}3}, @samp{rotl@var{m}3}, @samp{rotr@var{m}3} |
| 4799 | Other shift and rotate instructions, analogous to the |
| 4800 | @code{ashl@var{m}3} instructions. Operand 2 is always a scalar type. |
| 4801 | |
| 4802 | @cindex @code{vashl@var{m}3} instruction pattern |
| 4803 | @cindex @code{vashr@var{m}3} instruction pattern |
| 4804 | @cindex @code{vlshr@var{m}3} instruction pattern |
| 4805 | @cindex @code{vrotl@var{m}3} instruction pattern |
| 4806 | @cindex @code{vrotr@var{m}3} instruction pattern |
| 4807 | @item @samp{vashl@var{m}3}, @samp{vashr@var{m}3}, @samp{vlshr@var{m}3}, @samp{vrotl@var{m}3}, @samp{vrotr@var{m}3} |
| 4808 | Vector shift and rotate instructions that take vectors as operand 2 |
| 4809 | instead of a scalar type. |
| 4810 | |
| 4811 | @cindex @code{bswap@var{m}2} instruction pattern |
| 4812 | @item @samp{bswap@var{m}2} |
| 4813 | Reverse the order of bytes of operand 1 and store the result in operand 0. |
| 4814 | |
| 4815 | @cindex @code{neg@var{m}2} instruction pattern |
| 4816 | @cindex @code{ssneg@var{m}2} instruction pattern |
| 4817 | @cindex @code{usneg@var{m}2} instruction pattern |
| 4818 | @item @samp{neg@var{m}2}, @samp{ssneg@var{m}2}, @samp{usneg@var{m}2} |
| 4819 | Negate operand 1 and store the result in operand 0. |
| 4820 | |
| 4821 | @cindex @code{abs@var{m}2} instruction pattern |
| 4822 | @item @samp{abs@var{m}2} |
| 4823 | Store the absolute value of operand 1 into operand 0. |
| 4824 | |
| 4825 | @cindex @code{sqrt@var{m}2} instruction pattern |
| 4826 | @item @samp{sqrt@var{m}2} |
| 4827 | Store the square root of operand 1 into operand 0. |
| 4828 | |
| 4829 | The @code{sqrt} built-in function of C always uses the mode which |
| 4830 | corresponds to the C data type @code{double} and the @code{sqrtf} |
| 4831 | built-in function uses the mode which corresponds to the C data |
| 4832 | type @code{float}. |
| 4833 | |
| 4834 | @cindex @code{fmod@var{m}3} instruction pattern |
| 4835 | @item @samp{fmod@var{m}3} |
| 4836 | Store the remainder of dividing operand 1 by operand 2 into |
| 4837 | operand 0, rounded towards zero to an integer. |
| 4838 | |
| 4839 | The @code{fmod} built-in function of C always uses the mode which |
| 4840 | corresponds to the C data type @code{double} and the @code{fmodf} |
| 4841 | built-in function uses the mode which corresponds to the C data |
| 4842 | type @code{float}. |
| 4843 | |
| 4844 | @cindex @code{remainder@var{m}3} instruction pattern |
| 4845 | @item @samp{remainder@var{m}3} |
| 4846 | Store the remainder of dividing operand 1 by operand 2 into |
| 4847 | operand 0, rounded to the nearest integer. |
| 4848 | |
| 4849 | The @code{remainder} built-in function of C always uses the mode |
| 4850 | which corresponds to the C data type @code{double} and the |
| 4851 | @code{remainderf} built-in function uses the mode which corresponds |
| 4852 | to the C data type @code{float}. |
| 4853 | |
| 4854 | @cindex @code{cos@var{m}2} instruction pattern |
| 4855 | @item @samp{cos@var{m}2} |
| 4856 | Store the cosine of operand 1 into operand 0. |
| 4857 | |
| 4858 | The @code{cos} built-in function of C always uses the mode which |
| 4859 | corresponds to the C data type @code{double} and the @code{cosf} |
| 4860 | built-in function uses the mode which corresponds to the C data |
| 4861 | type @code{float}. |
| 4862 | |
| 4863 | @cindex @code{sin@var{m}2} instruction pattern |
| 4864 | @item @samp{sin@var{m}2} |
| 4865 | Store the sine of operand 1 into operand 0. |
| 4866 | |
| 4867 | The @code{sin} built-in function of C always uses the mode which |
| 4868 | corresponds to the C data type @code{double} and the @code{sinf} |
| 4869 | built-in function uses the mode which corresponds to the C data |
| 4870 | type @code{float}. |
| 4871 | |
| 4872 | @cindex @code{sincos@var{m}3} instruction pattern |
| 4873 | @item @samp{sincos@var{m}3} |
| 4874 | Store the sine of operand 2 into operand 0 and the cosine of |
| 4875 | operand 2 into operand 1. |
| 4876 | |
| 4877 | The @code{sin} and @code{cos} built-in functions of C always use the |
| 4878 | mode which corresponds to the C data type @code{double} and the |
| 4879 | @code{sinf} and @code{cosf} built-in function use the mode which |
| 4880 | corresponds to the C data type @code{float}. |
| 4881 | Targets that can calculate the sine and cosine simultaneously can |
| 4882 | implement this pattern as opposed to implementing individual |
| 4883 | @code{sin@var{m}2} and @code{cos@var{m}2} patterns. The @code{sin} |
| 4884 | and @code{cos} built-in functions will then be expanded to the |
| 4885 | @code{sincos@var{m}3} pattern, with one of the output values |
| 4886 | left unused. |
| 4887 | |
| 4888 | @cindex @code{exp@var{m}2} instruction pattern |
| 4889 | @item @samp{exp@var{m}2} |
| 4890 | Store the exponential of operand 1 into operand 0. |
| 4891 | |
| 4892 | The @code{exp} built-in function of C always uses the mode which |
| 4893 | corresponds to the C data type @code{double} and the @code{expf} |
| 4894 | built-in function uses the mode which corresponds to the C data |
| 4895 | type @code{float}. |
| 4896 | |
| 4897 | @cindex @code{log@var{m}2} instruction pattern |
| 4898 | @item @samp{log@var{m}2} |
| 4899 | Store the natural logarithm of operand 1 into operand 0. |
| 4900 | |
| 4901 | The @code{log} built-in function of C always uses the mode which |
| 4902 | corresponds to the C data type @code{double} and the @code{logf} |
| 4903 | built-in function uses the mode which corresponds to the C data |
| 4904 | type @code{float}. |
| 4905 | |
| 4906 | @cindex @code{pow@var{m}3} instruction pattern |
| 4907 | @item @samp{pow@var{m}3} |
| 4908 | Store the value of operand 1 raised to the exponent operand 2 |
| 4909 | into operand 0. |
| 4910 | |
| 4911 | The @code{pow} built-in function of C always uses the mode which |
| 4912 | corresponds to the C data type @code{double} and the @code{powf} |
| 4913 | built-in function uses the mode which corresponds to the C data |
| 4914 | type @code{float}. |
| 4915 | |
| 4916 | @cindex @code{atan2@var{m}3} instruction pattern |
| 4917 | @item @samp{atan2@var{m}3} |
| 4918 | Store the arc tangent (inverse tangent) of operand 1 divided by |
| 4919 | operand 2 into operand 0, using the signs of both arguments to |
| 4920 | determine the quadrant of the result. |
| 4921 | |
| 4922 | The @code{atan2} built-in function of C always uses the mode which |
| 4923 | corresponds to the C data type @code{double} and the @code{atan2f} |
| 4924 | built-in function uses the mode which corresponds to the C data |
| 4925 | type @code{float}. |
| 4926 | |
| 4927 | @cindex @code{floor@var{m}2} instruction pattern |
| 4928 | @item @samp{floor@var{m}2} |
| 4929 | Store the largest integral value not greater than argument. |
| 4930 | |
| 4931 | The @code{floor} built-in function of C always uses the mode which |
| 4932 | corresponds to the C data type @code{double} and the @code{floorf} |
| 4933 | built-in function uses the mode which corresponds to the C data |
| 4934 | type @code{float}. |
| 4935 | |
| 4936 | @cindex @code{btrunc@var{m}2} instruction pattern |
| 4937 | @item @samp{btrunc@var{m}2} |
| 4938 | Store the argument rounded to integer towards zero. |
| 4939 | |
| 4940 | The @code{trunc} built-in function of C always uses the mode which |
| 4941 | corresponds to the C data type @code{double} and the @code{truncf} |
| 4942 | built-in function uses the mode which corresponds to the C data |
| 4943 | type @code{float}. |
| 4944 | |
| 4945 | @cindex @code{round@var{m}2} instruction pattern |
| 4946 | @item @samp{round@var{m}2} |
| 4947 | Store the argument rounded to integer away from zero. |
| 4948 | |
| 4949 | The @code{round} built-in function of C always uses the mode which |
| 4950 | corresponds to the C data type @code{double} and the @code{roundf} |
| 4951 | built-in function uses the mode which corresponds to the C data |
| 4952 | type @code{float}. |
| 4953 | |
| 4954 | @cindex @code{ceil@var{m}2} instruction pattern |
| 4955 | @item @samp{ceil@var{m}2} |
| 4956 | Store the argument rounded to integer away from zero. |
| 4957 | |
| 4958 | The @code{ceil} built-in function of C always uses the mode which |
| 4959 | corresponds to the C data type @code{double} and the @code{ceilf} |
| 4960 | built-in function uses the mode which corresponds to the C data |
| 4961 | type @code{float}. |
| 4962 | |
| 4963 | @cindex @code{nearbyint@var{m}2} instruction pattern |
| 4964 | @item @samp{nearbyint@var{m}2} |
| 4965 | Store the argument rounded according to the default rounding mode |
| 4966 | |
| 4967 | The @code{nearbyint} built-in function of C always uses the mode which |
| 4968 | corresponds to the C data type @code{double} and the @code{nearbyintf} |
| 4969 | built-in function uses the mode which corresponds to the C data |
| 4970 | type @code{float}. |
| 4971 | |
| 4972 | @cindex @code{rint@var{m}2} instruction pattern |
| 4973 | @item @samp{rint@var{m}2} |
| 4974 | Store the argument rounded according to the default rounding mode and |
| 4975 | raise the inexact exception when the result differs in value from |
| 4976 | the argument |
| 4977 | |
| 4978 | The @code{rint} built-in function of C always uses the mode which |
| 4979 | corresponds to the C data type @code{double} and the @code{rintf} |
| 4980 | built-in function uses the mode which corresponds to the C data |
| 4981 | type @code{float}. |
| 4982 | |
| 4983 | @cindex @code{lrint@var{m}@var{n}2} |
| 4984 | @item @samp{lrint@var{m}@var{n}2} |
| 4985 | Convert operand 1 (valid for floating point mode @var{m}) to fixed |
| 4986 | point mode @var{n} as a signed number according to the current |
| 4987 | rounding mode and store in operand 0 (which has mode @var{n}). |
| 4988 | |
| 4989 | @cindex @code{lround@var{m}@var{n}2} |
| 4990 | @item @samp{lround@var{m}@var{n}2} |
| 4991 | Convert operand 1 (valid for floating point mode @var{m}) to fixed |
| 4992 | point mode @var{n} as a signed number rounding to nearest and away |
| 4993 | from zero and store in operand 0 (which has mode @var{n}). |
| 4994 | |
| 4995 | @cindex @code{lfloor@var{m}@var{n}2} |
| 4996 | @item @samp{lfloor@var{m}@var{n}2} |
| 4997 | Convert operand 1 (valid for floating point mode @var{m}) to fixed |
| 4998 | point mode @var{n} as a signed number rounding down and store in |
| 4999 | operand 0 (which has mode @var{n}). |
| 5000 | |
| 5001 | @cindex @code{lceil@var{m}@var{n}2} |
| 5002 | @item @samp{lceil@var{m}@var{n}2} |
| 5003 | Convert operand 1 (valid for floating point mode @var{m}) to fixed |
| 5004 | point mode @var{n} as a signed number rounding up and store in |
| 5005 | operand 0 (which has mode @var{n}). |
| 5006 | |
| 5007 | @cindex @code{copysign@var{m}3} instruction pattern |
| 5008 | @item @samp{copysign@var{m}3} |
| 5009 | Store a value with the magnitude of operand 1 and the sign of operand |
| 5010 | 2 into operand 0. |
| 5011 | |
| 5012 | The @code{copysign} built-in function of C always uses the mode which |
| 5013 | corresponds to the C data type @code{double} and the @code{copysignf} |
| 5014 | built-in function uses the mode which corresponds to the C data |
| 5015 | type @code{float}. |
| 5016 | |
| 5017 | @cindex @code{ffs@var{m}2} instruction pattern |
| 5018 | @item @samp{ffs@var{m}2} |
| 5019 | Store into operand 0 one plus the index of the least significant 1-bit |
| 5020 | of operand 1. If operand 1 is zero, store zero. @var{m} is the mode |
| 5021 | of operand 0; operand 1's mode is specified by the instruction |
| 5022 | pattern, and the compiler will convert the operand to that mode before |
| 5023 | generating the instruction. |
| 5024 | |
| 5025 | The @code{ffs} built-in function of C always uses the mode which |
| 5026 | corresponds to the C data type @code{int}. |
| 5027 | |
| 5028 | @cindex @code{clz@var{m}2} instruction pattern |
| 5029 | @item @samp{clz@var{m}2} |
| 5030 | Store into operand 0 the number of leading 0-bits in @var{x}, starting |
| 5031 | at the most significant bit position. If @var{x} is 0, the |
| 5032 | @code{CLZ_DEFINED_VALUE_AT_ZERO} (@pxref{Misc}) macro defines if |
| 5033 | the result is undefined or has a useful value. |
| 5034 | @var{m} is the mode of operand 0; operand 1's mode is |
| 5035 | specified by the instruction pattern, and the compiler will convert the |
| 5036 | operand to that mode before generating the instruction. |
| 5037 | |
| 5038 | @cindex @code{ctz@var{m}2} instruction pattern |
| 5039 | @item @samp{ctz@var{m}2} |
| 5040 | Store into operand 0 the number of trailing 0-bits in @var{x}, starting |
| 5041 | at the least significant bit position. If @var{x} is 0, the |
| 5042 | @code{CTZ_DEFINED_VALUE_AT_ZERO} (@pxref{Misc}) macro defines if |
| 5043 | the result is undefined or has a useful value. |
| 5044 | @var{m} is the mode of operand 0; operand 1's mode is |
| 5045 | specified by the instruction pattern, and the compiler will convert the |
| 5046 | operand to that mode before generating the instruction. |
| 5047 | |
| 5048 | @cindex @code{popcount@var{m}2} instruction pattern |
| 5049 | @item @samp{popcount@var{m}2} |
| 5050 | Store into operand 0 the number of 1-bits in @var{x}. @var{m} is the |
| 5051 | mode of operand 0; operand 1's mode is specified by the instruction |
| 5052 | pattern, and the compiler will convert the operand to that mode before |
| 5053 | generating the instruction. |
| 5054 | |
| 5055 | @cindex @code{parity@var{m}2} instruction pattern |
| 5056 | @item @samp{parity@var{m}2} |
| 5057 | Store into operand 0 the parity of @var{x}, i.e.@: the number of 1-bits |
| 5058 | in @var{x} modulo 2. @var{m} is the mode of operand 0; operand 1's mode |
| 5059 | is specified by the instruction pattern, and the compiler will convert |
| 5060 | the operand to that mode before generating the instruction. |
| 5061 | |
| 5062 | @cindex @code{one_cmpl@var{m}2} instruction pattern |
| 5063 | @item @samp{one_cmpl@var{m}2} |
| 5064 | Store the bitwise-complement of operand 1 into operand 0. |
| 5065 | |
| 5066 | @cindex @code{movmem@var{m}} instruction pattern |
| 5067 | @item @samp{movmem@var{m}} |
| 5068 | Block move instruction. The destination and source blocks of memory |
| 5069 | are the first two operands, and both are @code{mem:BLK}s with an |
| 5070 | address in mode @code{Pmode}. |
| 5071 | |
| 5072 | The number of bytes to move is the third operand, in mode @var{m}. |
| 5073 | Usually, you specify @code{word_mode} for @var{m}. However, if you can |
| 5074 | generate better code knowing the range of valid lengths is smaller than |
| 5075 | those representable in a full word, you should provide a pattern with a |
| 5076 | mode corresponding to the range of values you can handle efficiently |
| 5077 | (e.g., @code{QImode} for values in the range 0--127; note we avoid numbers |
| 5078 | that appear negative) and also a pattern with @code{word_mode}. |
| 5079 | |
| 5080 | The fourth operand is the known shared alignment of the source and |
| 5081 | destination, in the form of a @code{const_int} rtx. Thus, if the |
| 5082 | compiler knows that both source and destination are word-aligned, |
| 5083 | it may provide the value 4 for this operand. |
| 5084 | |
| 5085 | Optional operands 5 and 6 specify expected alignment and size of block |
| 5086 | respectively. The expected alignment differs from alignment in operand 4 |
| 5087 | in a way that the blocks are not required to be aligned according to it in |
| 5088 | all cases. This expected alignment is also in bytes, just like operand 4. |
| 5089 | Expected size, when unknown, is set to @code{(const_int -1)}. |
| 5090 | |
| 5091 | Descriptions of multiple @code{movmem@var{m}} patterns can only be |
| 5092 | beneficial if the patterns for smaller modes have fewer restrictions |
| 5093 | on their first, second and fourth operands. Note that the mode @var{m} |
| 5094 | in @code{movmem@var{m}} does not impose any restriction on the mode of |
| 5095 | individually moved data units in the block. |
| 5096 | |
| 5097 | These patterns need not give special consideration to the possibility |
| 5098 | that the source and destination strings might overlap. |
| 5099 | |
| 5100 | @cindex @code{movstr} instruction pattern |
| 5101 | @item @samp{movstr} |
| 5102 | String copy instruction, with @code{stpcpy} semantics. Operand 0 is |
| 5103 | an output operand in mode @code{Pmode}. The addresses of the |
| 5104 | destination and source strings are operands 1 and 2, and both are |
| 5105 | @code{mem:BLK}s with addresses in mode @code{Pmode}. The execution of |
| 5106 | the expansion of this pattern should store in operand 0 the address in |
| 5107 | which the @code{NUL} terminator was stored in the destination string. |
| 5108 | |
| 5109 | @cindex @code{setmem@var{m}} instruction pattern |
| 5110 | @item @samp{setmem@var{m}} |
| 5111 | Block set instruction. The destination string is the first operand, |
| 5112 | given as a @code{mem:BLK} whose address is in mode @code{Pmode}. The |
| 5113 | number of bytes to set is the second operand, in mode @var{m}. The value to |
| 5114 | initialize the memory with is the third operand. Targets that only support the |
| 5115 | clearing of memory should reject any value that is not the constant 0. See |
| 5116 | @samp{movmem@var{m}} for a discussion of the choice of mode. |
| 5117 | |
| 5118 | The fourth operand is the known alignment of the destination, in the form |
| 5119 | of a @code{const_int} rtx. Thus, if the compiler knows that the |
| 5120 | destination is word-aligned, it may provide the value 4 for this |
| 5121 | operand. |
| 5122 | |
| 5123 | Optional operands 5 and 6 specify expected alignment and size of block |
| 5124 | respectively. The expected alignment differs from alignment in operand 4 |
| 5125 | in a way that the blocks are not required to be aligned according to it in |
| 5126 | all cases. This expected alignment is also in bytes, just like operand 4. |
| 5127 | Expected size, when unknown, is set to @code{(const_int -1)}. |
| 5128 | |
| 5129 | The use for multiple @code{setmem@var{m}} is as for @code{movmem@var{m}}. |
| 5130 | |
| 5131 | @cindex @code{cmpstrn@var{m}} instruction pattern |
| 5132 | @item @samp{cmpstrn@var{m}} |
| 5133 | String compare instruction, with five operands. Operand 0 is the output; |
| 5134 | it has mode @var{m}. The remaining four operands are like the operands |
| 5135 | of @samp{movmem@var{m}}. The two memory blocks specified are compared |
| 5136 | byte by byte in lexicographic order starting at the beginning of each |
| 5137 | string. The instruction is not allowed to prefetch more than one byte |
| 5138 | at a time since either string may end in the first byte and reading past |
| 5139 | that may access an invalid page or segment and cause a fault. The |
| 5140 | comparison terminates early if the fetched bytes are different or if |
| 5141 | they are equal to zero. The effect of the instruction is to store a |
| 5142 | value in operand 0 whose sign indicates the result of the comparison. |
| 5143 | |
| 5144 | @cindex @code{cmpstr@var{m}} instruction pattern |
| 5145 | @item @samp{cmpstr@var{m}} |
| 5146 | String compare instruction, without known maximum length. Operand 0 is the |
| 5147 | output; it has mode @var{m}. The second and third operand are the blocks of |
| 5148 | memory to be compared; both are @code{mem:BLK} with an address in mode |
| 5149 | @code{Pmode}. |
| 5150 | |
| 5151 | The fourth operand is the known shared alignment of the source and |
| 5152 | destination, in the form of a @code{const_int} rtx. Thus, if the |
| 5153 | compiler knows that both source and destination are word-aligned, |
| 5154 | it may provide the value 4 for this operand. |
| 5155 | |
| 5156 | The two memory blocks specified are compared byte by byte in lexicographic |
| 5157 | order starting at the beginning of each string. The instruction is not allowed |
| 5158 | to prefetch more than one byte at a time since either string may end in the |
| 5159 | first byte and reading past that may access an invalid page or segment and |
| 5160 | cause a fault. The comparison will terminate when the fetched bytes |
| 5161 | are different or if they are equal to zero. The effect of the |
| 5162 | instruction is to store a value in operand 0 whose sign indicates the |
| 5163 | result of the comparison. |
| 5164 | |
| 5165 | @cindex @code{cmpmem@var{m}} instruction pattern |
| 5166 | @item @samp{cmpmem@var{m}} |
| 5167 | Block compare instruction, with five operands like the operands |
| 5168 | of @samp{cmpstr@var{m}}. The two memory blocks specified are compared |
| 5169 | byte by byte in lexicographic order starting at the beginning of each |
| 5170 | block. Unlike @samp{cmpstr@var{m}} the instruction can prefetch |
| 5171 | any bytes in the two memory blocks. Also unlike @samp{cmpstr@var{m}} |
| 5172 | the comparison will not stop if both bytes are zero. The effect of |
| 5173 | the instruction is to store a value in operand 0 whose sign indicates |
| 5174 | the result of the comparison. |
| 5175 | |
| 5176 | @cindex @code{strlen@var{m}} instruction pattern |
| 5177 | @item @samp{strlen@var{m}} |
| 5178 | Compute the length of a string, with three operands. |
| 5179 | Operand 0 is the result (of mode @var{m}), operand 1 is |
| 5180 | a @code{mem} referring to the first character of the string, |
| 5181 | operand 2 is the character to search for (normally zero), |
| 5182 | and operand 3 is a constant describing the known alignment |
| 5183 | of the beginning of the string. |
| 5184 | |
| 5185 | @cindex @code{float@var{m}@var{n}2} instruction pattern |
| 5186 | @item @samp{float@var{m}@var{n}2} |
| 5187 | Convert signed integer operand 1 (valid for fixed point mode @var{m}) to |
| 5188 | floating point mode @var{n} and store in operand 0 (which has mode |
| 5189 | @var{n}). |
| 5190 | |
| 5191 | @cindex @code{floatuns@var{m}@var{n}2} instruction pattern |
| 5192 | @item @samp{floatuns@var{m}@var{n}2} |
| 5193 | Convert unsigned integer operand 1 (valid for fixed point mode @var{m}) |
| 5194 | to floating point mode @var{n} and store in operand 0 (which has mode |
| 5195 | @var{n}). |
| 5196 | |
| 5197 | @cindex @code{fix@var{m}@var{n}2} instruction pattern |
| 5198 | @item @samp{fix@var{m}@var{n}2} |
| 5199 | Convert operand 1 (valid for floating point mode @var{m}) to fixed |
| 5200 | point mode @var{n} as a signed number and store in operand 0 (which |
| 5201 | has mode @var{n}). This instruction's result is defined only when |
| 5202 | the value of operand 1 is an integer. |
| 5203 | |
| 5204 | If the machine description defines this pattern, it also needs to |
| 5205 | define the @code{ftrunc} pattern. |
| 5206 | |
| 5207 | @cindex @code{fixuns@var{m}@var{n}2} instruction pattern |
| 5208 | @item @samp{fixuns@var{m}@var{n}2} |
| 5209 | Convert operand 1 (valid for floating point mode @var{m}) to fixed |
| 5210 | point mode @var{n} as an unsigned number and store in operand 0 (which |
| 5211 | has mode @var{n}). This instruction's result is defined only when the |
| 5212 | value of operand 1 is an integer. |
| 5213 | |
| 5214 | @cindex @code{ftrunc@var{m}2} instruction pattern |
| 5215 | @item @samp{ftrunc@var{m}2} |
| 5216 | Convert operand 1 (valid for floating point mode @var{m}) to an |
| 5217 | integer value, still represented in floating point mode @var{m}, and |
| 5218 | store it in operand 0 (valid for floating point mode @var{m}). |
| 5219 | |
| 5220 | @cindex @code{fix_trunc@var{m}@var{n}2} instruction pattern |
| 5221 | @item @samp{fix_trunc@var{m}@var{n}2} |
| 5222 | Like @samp{fix@var{m}@var{n}2} but works for any floating point value |
| 5223 | of mode @var{m} by converting the value to an integer. |
| 5224 | |
| 5225 | @cindex @code{fixuns_trunc@var{m}@var{n}2} instruction pattern |
| 5226 | @item @samp{fixuns_trunc@var{m}@var{n}2} |
| 5227 | Like @samp{fixuns@var{m}@var{n}2} but works for any floating point |
| 5228 | value of mode @var{m} by converting the value to an integer. |
| 5229 | |
| 5230 | @cindex @code{trunc@var{m}@var{n}2} instruction pattern |
| 5231 | @item @samp{trunc@var{m}@var{n}2} |
| 5232 | Truncate operand 1 (valid for mode @var{m}) to mode @var{n} and |
| 5233 | store in operand 0 (which has mode @var{n}). Both modes must be fixed |
| 5234 | point or both floating point. |
| 5235 | |
| 5236 | @cindex @code{extend@var{m}@var{n}2} instruction pattern |
| 5237 | @item @samp{extend@var{m}@var{n}2} |
| 5238 | Sign-extend operand 1 (valid for mode @var{m}) to mode @var{n} and |
| 5239 | store in operand 0 (which has mode @var{n}). Both modes must be fixed |
| 5240 | point or both floating point. |
| 5241 | |
| 5242 | @cindex @code{zero_extend@var{m}@var{n}2} instruction pattern |
| 5243 | @item @samp{zero_extend@var{m}@var{n}2} |
| 5244 | Zero-extend operand 1 (valid for mode @var{m}) to mode @var{n} and |
| 5245 | store in operand 0 (which has mode @var{n}). Both modes must be fixed |
| 5246 | point. |
| 5247 | |
| 5248 | @cindex @code{fract@var{m}@var{n}2} instruction pattern |
| 5249 | @item @samp{fract@var{m}@var{n}2} |
| 5250 | Convert operand 1 of mode @var{m} to mode @var{n} and store in |
| 5251 | operand 0 (which has mode @var{n}). Mode @var{m} and mode @var{n} |
| 5252 | could be fixed-point to fixed-point, signed integer to fixed-point, |
| 5253 | fixed-point to signed integer, floating-point to fixed-point, |
| 5254 | or fixed-point to floating-point. |
| 5255 | When overflows or underflows happen, the results are undefined. |
| 5256 | |
| 5257 | @cindex @code{satfract@var{m}@var{n}2} instruction pattern |
| 5258 | @item @samp{satfract@var{m}@var{n}2} |
| 5259 | Convert operand 1 of mode @var{m} to mode @var{n} and store in |
| 5260 | operand 0 (which has mode @var{n}). Mode @var{m} and mode @var{n} |
| 5261 | could be fixed-point to fixed-point, signed integer to fixed-point, |
| 5262 | or floating-point to fixed-point. |
| 5263 | When overflows or underflows happen, the instruction saturates the |
| 5264 | results to the maximum or the minimum. |
| 5265 | |
| 5266 | @cindex @code{fractuns@var{m}@var{n}2} instruction pattern |
| 5267 | @item @samp{fractuns@var{m}@var{n}2} |
| 5268 | Convert operand 1 of mode @var{m} to mode @var{n} and store in |
| 5269 | operand 0 (which has mode @var{n}). Mode @var{m} and mode @var{n} |
| 5270 | could be unsigned integer to fixed-point, or |
| 5271 | fixed-point to unsigned integer. |
| 5272 | When overflows or underflows happen, the results are undefined. |
| 5273 | |
| 5274 | @cindex @code{satfractuns@var{m}@var{n}2} instruction pattern |
| 5275 | @item @samp{satfractuns@var{m}@var{n}2} |
| 5276 | Convert unsigned integer operand 1 of mode @var{m} to fixed-point mode |
| 5277 | @var{n} and store in operand 0 (which has mode @var{n}). |
| 5278 | When overflows or underflows happen, the instruction saturates the |
| 5279 | results to the maximum or the minimum. |
| 5280 | |
| 5281 | @cindex @code{extv} instruction pattern |
| 5282 | @item @samp{extv} |
| 5283 | Extract a bit-field from operand 1 (a register or memory operand), where |
| 5284 | operand 2 specifies the width in bits and operand 3 the starting bit, |
| 5285 | and store it in operand 0. Operand 0 must have mode @code{word_mode}. |
| 5286 | Operand 1 may have mode @code{byte_mode} or @code{word_mode}; often |
| 5287 | @code{word_mode} is allowed only for registers. Operands 2 and 3 must |
| 5288 | be valid for @code{word_mode}. |
| 5289 | |
| 5290 | The RTL generation pass generates this instruction only with constants |
| 5291 | for operands 2 and 3 and the constant is never zero for operand 2. |
| 5292 | |
| 5293 | The bit-field value is sign-extended to a full word integer |
| 5294 | before it is stored in operand 0. |
| 5295 | |
| 5296 | @cindex @code{extzv} instruction pattern |
| 5297 | @item @samp{extzv} |
| 5298 | Like @samp{extv} except that the bit-field value is zero-extended. |
| 5299 | |
| 5300 | @cindex @code{insv} instruction pattern |
| 5301 | @item @samp{insv} |
| 5302 | Store operand 3 (which must be valid for @code{word_mode}) into a |
| 5303 | bit-field in operand 0, where operand 1 specifies the width in bits and |
| 5304 | operand 2 the starting bit. Operand 0 may have mode @code{byte_mode} or |
| 5305 | @code{word_mode}; often @code{word_mode} is allowed only for registers. |
| 5306 | Operands 1 and 2 must be valid for @code{word_mode}. |
| 5307 | |
| 5308 | The RTL generation pass generates this instruction only with constants |
| 5309 | for operands 1 and 2 and the constant is never zero for operand 1. |
| 5310 | |
| 5311 | @cindex @code{mov@var{mode}cc} instruction pattern |
| 5312 | @item @samp{mov@var{mode}cc} |
| 5313 | Conditionally move operand 2 or operand 3 into operand 0 according to the |
| 5314 | comparison in operand 1. If the comparison is true, operand 2 is moved |
| 5315 | into operand 0, otherwise operand 3 is moved. |
| 5316 | |
| 5317 | The mode of the operands being compared need not be the same as the operands |
| 5318 | being moved. Some machines, sparc64 for example, have instructions that |
| 5319 | conditionally move an integer value based on the floating point condition |
| 5320 | codes and vice versa. |
| 5321 | |
| 5322 | If the machine does not have conditional move instructions, do not |
| 5323 | define these patterns. |
| 5324 | |
| 5325 | @cindex @code{add@var{mode}cc} instruction pattern |
| 5326 | @item @samp{add@var{mode}cc} |
| 5327 | Similar to @samp{mov@var{mode}cc} but for conditional addition. Conditionally |
| 5328 | move operand 2 or (operands 2 + operand 3) into operand 0 according to the |
| 5329 | comparison in operand 1. If the comparison is false, operand 2 is moved into |
| 5330 | operand 0, otherwise (operand 2 + operand 3) is moved. |
| 5331 | |
| 5332 | @cindex @code{cstore@var{mode}4} instruction pattern |
| 5333 | @item @samp{cstore@var{mode}4} |
| 5334 | Store zero or nonzero in operand 0 according to whether a comparison |
| 5335 | is true. Operand 1 is a comparison operator. Operand 2 and operand 3 |
| 5336 | are the first and second operand of the comparison, respectively. |
| 5337 | You specify the mode that operand 0 must have when you write the |
| 5338 | @code{match_operand} expression. The compiler automatically sees which |
| 5339 | mode you have used and supplies an operand of that mode. |
| 5340 | |
| 5341 | The value stored for a true condition must have 1 as its low bit, or |
| 5342 | else must be negative. Otherwise the instruction is not suitable and |
| 5343 | you should omit it from the machine description. You describe to the |
| 5344 | compiler exactly which value is stored by defining the macro |
| 5345 | @code{STORE_FLAG_VALUE} (@pxref{Misc}). If a description cannot be |
| 5346 | found that can be used for all the possible comparison operators, you |
| 5347 | should pick one and use a @code{define_expand} to map all results |
| 5348 | onto the one you chose. |
| 5349 | |
| 5350 | These operations may @code{FAIL}, but should do so only in relatively |
| 5351 | uncommon cases; if they would @code{FAIL} for common cases involving |
| 5352 | integer comparisons, it is best to restrict the predicates to not |
| 5353 | allow these operands. Likewise if a given comparison operator will |
| 5354 | always fail, independent of the operands (for floating-point modes, the |
| 5355 | @code{ordered_comparison_operator} predicate is often useful in this case). |
| 5356 | |
| 5357 | If this pattern is omitted, the compiler will generate a conditional |
| 5358 | branch---for example, it may copy a constant one to the target and branching |
| 5359 | around an assignment of zero to the target---or a libcall. If the predicate |
| 5360 | for operand 1 only rejects some operators, it will also try reordering the |
| 5361 | operands and/or inverting the result value (e.g.@: by an exclusive OR). |
| 5362 | These possibilities could be cheaper or equivalent to the instructions |
| 5363 | used for the @samp{cstore@var{mode}4} pattern followed by those required |
| 5364 | to convert a positive result from @code{STORE_FLAG_VALUE} to 1; in this |
| 5365 | case, you can and should make operand 1's predicate reject some operators |
| 5366 | in the @samp{cstore@var{mode}4} pattern, or remove the pattern altogether |
| 5367 | from the machine description. |
| 5368 | |
| 5369 | @cindex @code{cbranch@var{mode}4} instruction pattern |
| 5370 | @item @samp{cbranch@var{mode}4} |
| 5371 | Conditional branch instruction combined with a compare instruction. |
| 5372 | Operand 0 is a comparison operator. Operand 1 and operand 2 are the |
| 5373 | first and second operands of the comparison, respectively. Operand 3 |
| 5374 | is a @code{label_ref} that refers to the label to jump to. |
| 5375 | |
| 5376 | @cindex @code{jump} instruction pattern |
| 5377 | @item @samp{jump} |
| 5378 | A jump inside a function; an unconditional branch. Operand 0 is the |
| 5379 | @code{label_ref} of the label to jump to. This pattern name is mandatory |
| 5380 | on all machines. |
| 5381 | |
| 5382 | @cindex @code{call} instruction pattern |
| 5383 | @item @samp{call} |
| 5384 | Subroutine call instruction returning no value. Operand 0 is the |
| 5385 | function to call; operand 1 is the number of bytes of arguments pushed |
| 5386 | as a @code{const_int}; operand 2 is the number of registers used as |
| 5387 | operands. |
| 5388 | |
| 5389 | On most machines, operand 2 is not actually stored into the RTL |
| 5390 | pattern. It is supplied for the sake of some RISC machines which need |
| 5391 | to put this information into the assembler code; they can put it in |
| 5392 | the RTL instead of operand 1. |
| 5393 | |
| 5394 | Operand 0 should be a @code{mem} RTX whose address is the address of the |
| 5395 | function. Note, however, that this address can be a @code{symbol_ref} |
| 5396 | expression even if it would not be a legitimate memory address on the |
| 5397 | target machine. If it is also not a valid argument for a call |
| 5398 | instruction, the pattern for this operation should be a |
| 5399 | @code{define_expand} (@pxref{Expander Definitions}) that places the |
| 5400 | address into a register and uses that register in the call instruction. |
| 5401 | |
| 5402 | @cindex @code{call_value} instruction pattern |
| 5403 | @item @samp{call_value} |
| 5404 | Subroutine call instruction returning a value. Operand 0 is the hard |
| 5405 | register in which the value is returned. There are three more |
| 5406 | operands, the same as the three operands of the @samp{call} |
| 5407 | instruction (but with numbers increased by one). |
| 5408 | |
| 5409 | Subroutines that return @code{BLKmode} objects use the @samp{call} |
| 5410 | insn. |
| 5411 | |
| 5412 | @cindex @code{call_pop} instruction pattern |
| 5413 | @cindex @code{call_value_pop} instruction pattern |
| 5414 | @item @samp{call_pop}, @samp{call_value_pop} |
| 5415 | Similar to @samp{call} and @samp{call_value}, except used if defined and |
| 5416 | if @code{RETURN_POPS_ARGS} is nonzero. They should emit a @code{parallel} |
| 5417 | that contains both the function call and a @code{set} to indicate the |
| 5418 | adjustment made to the frame pointer. |
| 5419 | |
| 5420 | For machines where @code{RETURN_POPS_ARGS} can be nonzero, the use of these |
| 5421 | patterns increases the number of functions for which the frame pointer |
| 5422 | can be eliminated, if desired. |
| 5423 | |
| 5424 | @cindex @code{untyped_call} instruction pattern |
| 5425 | @item @samp{untyped_call} |
| 5426 | Subroutine call instruction returning a value of any type. Operand 0 is |
| 5427 | the function to call; operand 1 is a memory location where the result of |
| 5428 | calling the function is to be stored; operand 2 is a @code{parallel} |
| 5429 | expression where each element is a @code{set} expression that indicates |
| 5430 | the saving of a function return value into the result block. |
| 5431 | |
| 5432 | This instruction pattern should be defined to support |
| 5433 | @code{__builtin_apply} on machines where special instructions are needed |
| 5434 | to call a subroutine with arbitrary arguments or to save the value |
| 5435 | returned. This instruction pattern is required on machines that have |
| 5436 | multiple registers that can hold a return value |
| 5437 | (i.e.@: @code{FUNCTION_VALUE_REGNO_P} is true for more than one register). |
| 5438 | |
| 5439 | @cindex @code{return} instruction pattern |
| 5440 | @item @samp{return} |
| 5441 | Subroutine return instruction. This instruction pattern name should be |
| 5442 | defined only if a single instruction can do all the work of returning |
| 5443 | from a function. |
| 5444 | |
| 5445 | Like the @samp{mov@var{m}} patterns, this pattern is also used after the |
| 5446 | RTL generation phase. In this case it is to support machines where |
| 5447 | multiple instructions are usually needed to return from a function, but |
| 5448 | some class of functions only requires one instruction to implement a |
| 5449 | return. Normally, the applicable functions are those which do not need |
| 5450 | to save any registers or allocate stack space. |
| 5451 | |
| 5452 | It is valid for this pattern to expand to an instruction using |
| 5453 | @code{simple_return} if no epilogue is required. |
| 5454 | |
| 5455 | @cindex @code{simple_return} instruction pattern |
| 5456 | @item @samp{simple_return} |
| 5457 | Subroutine return instruction. This instruction pattern name should be |
| 5458 | defined only if a single instruction can do all the work of returning |
| 5459 | from a function on a path where no epilogue is required. This pattern |
| 5460 | is very similar to the @code{return} instruction pattern, but it is emitted |
| 5461 | only by the shrink-wrapping optimization on paths where the function |
| 5462 | prologue has not been executed, and a function return should occur without |
| 5463 | any of the effects of the epilogue. Additional uses may be introduced on |
| 5464 | paths where both the prologue and the epilogue have executed. |
| 5465 | |
| 5466 | @findex reload_completed |
| 5467 | @findex leaf_function_p |
| 5468 | For such machines, the condition specified in this pattern should only |
| 5469 | be true when @code{reload_completed} is nonzero and the function's |
| 5470 | epilogue would only be a single instruction. For machines with register |
| 5471 | windows, the routine @code{leaf_function_p} may be used to determine if |
| 5472 | a register window push is required. |
| 5473 | |
| 5474 | Machines that have conditional return instructions should define patterns |
| 5475 | such as |
| 5476 | |
| 5477 | @smallexample |
| 5478 | (define_insn "" |
| 5479 | [(set (pc) |
| 5480 | (if_then_else (match_operator |
| 5481 | 0 "comparison_operator" |
| 5482 | [(cc0) (const_int 0)]) |
| 5483 | (return) |
| 5484 | (pc)))] |
| 5485 | "@var{condition}" |
| 5486 | "@dots{}") |
| 5487 | @end smallexample |
| 5488 | |
| 5489 | where @var{condition} would normally be the same condition specified on the |
| 5490 | named @samp{return} pattern. |
| 5491 | |
| 5492 | @cindex @code{untyped_return} instruction pattern |
| 5493 | @item @samp{untyped_return} |
| 5494 | Untyped subroutine return instruction. This instruction pattern should |
| 5495 | be defined to support @code{__builtin_return} on machines where special |
| 5496 | instructions are needed to return a value of any type. |
| 5497 | |
| 5498 | Operand 0 is a memory location where the result of calling a function |
| 5499 | with @code{__builtin_apply} is stored; operand 1 is a @code{parallel} |
| 5500 | expression where each element is a @code{set} expression that indicates |
| 5501 | the restoring of a function return value from the result block. |
| 5502 | |
| 5503 | @cindex @code{nop} instruction pattern |
| 5504 | @item @samp{nop} |
| 5505 | No-op instruction. This instruction pattern name should always be defined |
| 5506 | to output a no-op in assembler code. @code{(const_int 0)} will do as an |
| 5507 | RTL pattern. |
| 5508 | |
| 5509 | @cindex @code{indirect_jump} instruction pattern |
| 5510 | @item @samp{indirect_jump} |
| 5511 | An instruction to jump to an address which is operand zero. |
| 5512 | This pattern name is mandatory on all machines. |
| 5513 | |
| 5514 | @cindex @code{casesi} instruction pattern |
| 5515 | @item @samp{casesi} |
| 5516 | Instruction to jump through a dispatch table, including bounds checking. |
| 5517 | This instruction takes five operands: |
| 5518 | |
| 5519 | @enumerate |
| 5520 | @item |
| 5521 | The index to dispatch on, which has mode @code{SImode}. |
| 5522 | |
| 5523 | @item |
| 5524 | The lower bound for indices in the table, an integer constant. |
| 5525 | |
| 5526 | @item |
| 5527 | The total range of indices in the table---the largest index |
| 5528 | minus the smallest one (both inclusive). |
| 5529 | |
| 5530 | @item |
| 5531 | A label that precedes the table itself. |
| 5532 | |
| 5533 | @item |
| 5534 | A label to jump to if the index has a value outside the bounds. |
| 5535 | @end enumerate |
| 5536 | |
| 5537 | The table is an @code{addr_vec} or @code{addr_diff_vec} inside of a |
| 5538 | @code{jump_insn}. The number of elements in the table is one plus the |
| 5539 | difference between the upper bound and the lower bound. |
| 5540 | |
| 5541 | @cindex @code{tablejump} instruction pattern |
| 5542 | @item @samp{tablejump} |
| 5543 | Instruction to jump to a variable address. This is a low-level |
| 5544 | capability which can be used to implement a dispatch table when there |
| 5545 | is no @samp{casesi} pattern. |
| 5546 | |
| 5547 | This pattern requires two operands: the address or offset, and a label |
| 5548 | which should immediately precede the jump table. If the macro |
| 5549 | @code{CASE_VECTOR_PC_RELATIVE} evaluates to a nonzero value then the first |
| 5550 | operand is an offset which counts from the address of the table; otherwise, |
| 5551 | it is an absolute address to jump to. In either case, the first operand has |
| 5552 | mode @code{Pmode}. |
| 5553 | |
| 5554 | The @samp{tablejump} insn is always the last insn before the jump |
| 5555 | table it uses. Its assembler code normally has no need to use the |
| 5556 | second operand, but you should incorporate it in the RTL pattern so |
| 5557 | that the jump optimizer will not delete the table as unreachable code. |
| 5558 | |
| 5559 | |
| 5560 | @cindex @code{decrement_and_branch_until_zero} instruction pattern |
| 5561 | @item @samp{decrement_and_branch_until_zero} |
| 5562 | Conditional branch instruction that decrements a register and |
| 5563 | jumps if the register is nonzero. Operand 0 is the register to |
| 5564 | decrement and test; operand 1 is the label to jump to if the |
| 5565 | register is nonzero. @xref{Looping Patterns}. |
| 5566 | |
| 5567 | This optional instruction pattern is only used by the combiner, |
| 5568 | typically for loops reversed by the loop optimizer when strength |
| 5569 | reduction is enabled. |
| 5570 | |
| 5571 | @cindex @code{doloop_end} instruction pattern |
| 5572 | @item @samp{doloop_end} |
| 5573 | Conditional branch instruction that decrements a register and jumps if |
| 5574 | the register is nonzero. This instruction takes five operands: Operand |
| 5575 | 0 is the register to decrement and test; operand 1 is the number of loop |
| 5576 | iterations as a @code{const_int} or @code{const0_rtx} if this cannot be |
| 5577 | determined until run-time; operand 2 is the actual or estimated maximum |
| 5578 | number of iterations as a @code{const_int}; operand 3 is the number of |
| 5579 | enclosed loops as a @code{const_int} (an innermost loop has a value of |
Bernhard Rosenkraenzer | 7d3ad0b | 2012-10-23 01:39:53 +0159 | [diff] [blame^] | 5580 | 1); operand 4 is the label to jump to if the register is nonzero; |
| 5581 | operand 5 is const1_rtx if the loop in entered at its top, const0_rtx |
| 5582 | otherwise. |
Bernhard Rosenkraenzer | c83ebe5 | 2012-09-18 21:38:03 +0159 | [diff] [blame] | 5583 | @xref{Looping Patterns}. |
| 5584 | |
| 5585 | This optional instruction pattern should be defined for machines with |
| 5586 | low-overhead looping instructions as the loop optimizer will try to |
| 5587 | modify suitable loops to utilize it. If nested low-overhead looping is |
| 5588 | not supported, use a @code{define_expand} (@pxref{Expander Definitions}) |
| 5589 | and make the pattern fail if operand 3 is not @code{const1_rtx}. |
| 5590 | Similarly, if the actual or estimated maximum number of iterations is |
| 5591 | too large for this instruction, make it fail. |
| 5592 | |
| 5593 | @cindex @code{doloop_begin} instruction pattern |
| 5594 | @item @samp{doloop_begin} |
| 5595 | Companion instruction to @code{doloop_end} required for machines that |
| 5596 | need to perform some initialization, such as loading special registers |
| 5597 | used by a low-overhead looping instruction. If initialization insns do |
| 5598 | not always need to be emitted, use a @code{define_expand} |
| 5599 | (@pxref{Expander Definitions}) and make it fail. |
| 5600 | |
| 5601 | |
| 5602 | @cindex @code{canonicalize_funcptr_for_compare} instruction pattern |
| 5603 | @item @samp{canonicalize_funcptr_for_compare} |
| 5604 | Canonicalize the function pointer in operand 1 and store the result |
| 5605 | into operand 0. |
| 5606 | |
| 5607 | Operand 0 is always a @code{reg} and has mode @code{Pmode}; operand 1 |
| 5608 | may be a @code{reg}, @code{mem}, @code{symbol_ref}, @code{const_int}, etc |
| 5609 | and also has mode @code{Pmode}. |
| 5610 | |
| 5611 | Canonicalization of a function pointer usually involves computing |
| 5612 | the address of the function which would be called if the function |
| 5613 | pointer were used in an indirect call. |
| 5614 | |
| 5615 | Only define this pattern if function pointers on the target machine |
| 5616 | can have different values but still call the same function when |
| 5617 | used in an indirect call. |
| 5618 | |
| 5619 | @cindex @code{save_stack_block} instruction pattern |
| 5620 | @cindex @code{save_stack_function} instruction pattern |
| 5621 | @cindex @code{save_stack_nonlocal} instruction pattern |
| 5622 | @cindex @code{restore_stack_block} instruction pattern |
| 5623 | @cindex @code{restore_stack_function} instruction pattern |
| 5624 | @cindex @code{restore_stack_nonlocal} instruction pattern |
| 5625 | @item @samp{save_stack_block} |
| 5626 | @itemx @samp{save_stack_function} |
| 5627 | @itemx @samp{save_stack_nonlocal} |
| 5628 | @itemx @samp{restore_stack_block} |
| 5629 | @itemx @samp{restore_stack_function} |
| 5630 | @itemx @samp{restore_stack_nonlocal} |
| 5631 | Most machines save and restore the stack pointer by copying it to or |
| 5632 | from an object of mode @code{Pmode}. Do not define these patterns on |
| 5633 | such machines. |
| 5634 | |
| 5635 | Some machines require special handling for stack pointer saves and |
| 5636 | restores. On those machines, define the patterns corresponding to the |
| 5637 | non-standard cases by using a @code{define_expand} (@pxref{Expander |
| 5638 | Definitions}) that produces the required insns. The three types of |
| 5639 | saves and restores are: |
| 5640 | |
| 5641 | @enumerate |
| 5642 | @item |
| 5643 | @samp{save_stack_block} saves the stack pointer at the start of a block |
| 5644 | that allocates a variable-sized object, and @samp{restore_stack_block} |
| 5645 | restores the stack pointer when the block is exited. |
| 5646 | |
| 5647 | @item |
| 5648 | @samp{save_stack_function} and @samp{restore_stack_function} do a |
| 5649 | similar job for the outermost block of a function and are used when the |
| 5650 | function allocates variable-sized objects or calls @code{alloca}. Only |
| 5651 | the epilogue uses the restored stack pointer, allowing a simpler save or |
| 5652 | restore sequence on some machines. |
| 5653 | |
| 5654 | @item |
| 5655 | @samp{save_stack_nonlocal} is used in functions that contain labels |
| 5656 | branched to by nested functions. It saves the stack pointer in such a |
| 5657 | way that the inner function can use @samp{restore_stack_nonlocal} to |
| 5658 | restore the stack pointer. The compiler generates code to restore the |
| 5659 | frame and argument pointer registers, but some machines require saving |
| 5660 | and restoring additional data such as register window information or |
| 5661 | stack backchains. Place insns in these patterns to save and restore any |
| 5662 | such required data. |
| 5663 | @end enumerate |
| 5664 | |
| 5665 | When saving the stack pointer, operand 0 is the save area and operand 1 |
| 5666 | is the stack pointer. The mode used to allocate the save area defaults |
| 5667 | to @code{Pmode} but you can override that choice by defining the |
| 5668 | @code{STACK_SAVEAREA_MODE} macro (@pxref{Storage Layout}). You must |
| 5669 | specify an integral mode, or @code{VOIDmode} if no save area is needed |
| 5670 | for a particular type of save (either because no save is needed or |
| 5671 | because a machine-specific save area can be used). Operand 0 is the |
| 5672 | stack pointer and operand 1 is the save area for restore operations. If |
| 5673 | @samp{save_stack_block} is defined, operand 0 must not be |
| 5674 | @code{VOIDmode} since these saves can be arbitrarily nested. |
| 5675 | |
| 5676 | A save area is a @code{mem} that is at a constant offset from |
| 5677 | @code{virtual_stack_vars_rtx} when the stack pointer is saved for use by |
| 5678 | nonlocal gotos and a @code{reg} in the other two cases. |
| 5679 | |
| 5680 | @cindex @code{allocate_stack} instruction pattern |
| 5681 | @item @samp{allocate_stack} |
| 5682 | Subtract (or add if @code{STACK_GROWS_DOWNWARD} is undefined) operand 1 from |
| 5683 | the stack pointer to create space for dynamically allocated data. |
| 5684 | |
| 5685 | Store the resultant pointer to this space into operand 0. If you |
| 5686 | are allocating space from the main stack, do this by emitting a |
| 5687 | move insn to copy @code{virtual_stack_dynamic_rtx} to operand 0. |
| 5688 | If you are allocating the space elsewhere, generate code to copy the |
| 5689 | location of the space to operand 0. In the latter case, you must |
| 5690 | ensure this space gets freed when the corresponding space on the main |
| 5691 | stack is free. |
| 5692 | |
| 5693 | Do not define this pattern if all that must be done is the subtraction. |
| 5694 | Some machines require other operations such as stack probes or |
| 5695 | maintaining the back chain. Define this pattern to emit those |
| 5696 | operations in addition to updating the stack pointer. |
| 5697 | |
| 5698 | @cindex @code{check_stack} instruction pattern |
| 5699 | @item @samp{check_stack} |
| 5700 | If stack checking (@pxref{Stack Checking}) cannot be done on your system by |
| 5701 | probing the stack, define this pattern to perform the needed check and signal |
| 5702 | an error if the stack has overflowed. The single operand is the address in |
| 5703 | the stack farthest from the current stack pointer that you need to validate. |
| 5704 | Normally, on platforms where this pattern is needed, you would obtain the |
| 5705 | stack limit from a global or thread-specific variable or register. |
| 5706 | |
| 5707 | @cindex @code{probe_stack_address} instruction pattern |
| 5708 | @item @samp{probe_stack_address} |
| 5709 | If stack checking (@pxref{Stack Checking}) can be done on your system by |
| 5710 | probing the stack but without the need to actually access it, define this |
| 5711 | pattern and signal an error if the stack has overflowed. The single operand |
| 5712 | is the memory address in the stack that needs to be probed. |
| 5713 | |
| 5714 | @cindex @code{probe_stack} instruction pattern |
| 5715 | @item @samp{probe_stack} |
| 5716 | If stack checking (@pxref{Stack Checking}) can be done on your system by |
| 5717 | probing the stack but doing it with a ``store zero'' instruction is not valid |
| 5718 | or optimal, define this pattern to do the probing differently and signal an |
| 5719 | error if the stack has overflowed. The single operand is the memory reference |
| 5720 | in the stack that needs to be probed. |
| 5721 | |
| 5722 | @cindex @code{nonlocal_goto} instruction pattern |
| 5723 | @item @samp{nonlocal_goto} |
| 5724 | Emit code to generate a non-local goto, e.g., a jump from one function |
| 5725 | to a label in an outer function. This pattern has four arguments, |
| 5726 | each representing a value to be used in the jump. The first |
| 5727 | argument is to be loaded into the frame pointer, the second is |
| 5728 | the address to branch to (code to dispatch to the actual label), |
| 5729 | the third is the address of a location where the stack is saved, |
| 5730 | and the last is the address of the label, to be placed in the |
| 5731 | location for the incoming static chain. |
| 5732 | |
| 5733 | On most machines you need not define this pattern, since GCC will |
| 5734 | already generate the correct code, which is to load the frame pointer |
| 5735 | and static chain, restore the stack (using the |
| 5736 | @samp{restore_stack_nonlocal} pattern, if defined), and jump indirectly |
| 5737 | to the dispatcher. You need only define this pattern if this code will |
| 5738 | not work on your machine. |
| 5739 | |
| 5740 | @cindex @code{nonlocal_goto_receiver} instruction pattern |
| 5741 | @item @samp{nonlocal_goto_receiver} |
| 5742 | This pattern, if defined, contains code needed at the target of a |
| 5743 | nonlocal goto after the code already generated by GCC@. You will not |
| 5744 | normally need to define this pattern. A typical reason why you might |
| 5745 | need this pattern is if some value, such as a pointer to a global table, |
| 5746 | must be restored when the frame pointer is restored. Note that a nonlocal |
| 5747 | goto only occurs within a unit-of-translation, so a global table pointer |
| 5748 | that is shared by all functions of a given module need not be restored. |
| 5749 | There are no arguments. |
| 5750 | |
| 5751 | @cindex @code{exception_receiver} instruction pattern |
| 5752 | @item @samp{exception_receiver} |
| 5753 | This pattern, if defined, contains code needed at the site of an |
| 5754 | exception handler that isn't needed at the site of a nonlocal goto. You |
| 5755 | will not normally need to define this pattern. A typical reason why you |
| 5756 | might need this pattern is if some value, such as a pointer to a global |
| 5757 | table, must be restored after control flow is branched to the handler of |
| 5758 | an exception. There are no arguments. |
| 5759 | |
| 5760 | @cindex @code{builtin_setjmp_setup} instruction pattern |
| 5761 | @item @samp{builtin_setjmp_setup} |
| 5762 | This pattern, if defined, contains additional code needed to initialize |
| 5763 | the @code{jmp_buf}. You will not normally need to define this pattern. |
| 5764 | A typical reason why you might need this pattern is if some value, such |
| 5765 | as a pointer to a global table, must be restored. Though it is |
| 5766 | preferred that the pointer value be recalculated if possible (given the |
| 5767 | address of a label for instance). The single argument is a pointer to |
| 5768 | the @code{jmp_buf}. Note that the buffer is five words long and that |
| 5769 | the first three are normally used by the generic mechanism. |
| 5770 | |
| 5771 | @cindex @code{builtin_setjmp_receiver} instruction pattern |
| 5772 | @item @samp{builtin_setjmp_receiver} |
| 5773 | This pattern, if defined, contains code needed at the site of a |
| 5774 | built-in setjmp that isn't needed at the site of a nonlocal goto. You |
| 5775 | will not normally need to define this pattern. A typical reason why you |
| 5776 | might need this pattern is if some value, such as a pointer to a global |
| 5777 | table, must be restored. It takes one argument, which is the label |
| 5778 | to which builtin_longjmp transferred control; this pattern may be emitted |
| 5779 | at a small offset from that label. |
| 5780 | |
| 5781 | @cindex @code{builtin_longjmp} instruction pattern |
| 5782 | @item @samp{builtin_longjmp} |
| 5783 | This pattern, if defined, performs the entire action of the longjmp. |
| 5784 | You will not normally need to define this pattern unless you also define |
| 5785 | @code{builtin_setjmp_setup}. The single argument is a pointer to the |
| 5786 | @code{jmp_buf}. |
| 5787 | |
| 5788 | @cindex @code{eh_return} instruction pattern |
| 5789 | @item @samp{eh_return} |
| 5790 | This pattern, if defined, affects the way @code{__builtin_eh_return}, |
| 5791 | and thence the call frame exception handling library routines, are |
| 5792 | built. It is intended to handle non-trivial actions needed along |
| 5793 | the abnormal return path. |
| 5794 | |
| 5795 | The address of the exception handler to which the function should return |
| 5796 | is passed as operand to this pattern. It will normally need to copied by |
| 5797 | the pattern to some special register or memory location. |
| 5798 | If the pattern needs to determine the location of the target call |
| 5799 | frame in order to do so, it may use @code{EH_RETURN_STACKADJ_RTX}, |
| 5800 | if defined; it will have already been assigned. |
| 5801 | |
| 5802 | If this pattern is not defined, the default action will be to simply |
| 5803 | copy the return address to @code{EH_RETURN_HANDLER_RTX}. Either |
| 5804 | that macro or this pattern needs to be defined if call frame exception |
| 5805 | handling is to be used. |
| 5806 | |
| 5807 | @cindex @code{prologue} instruction pattern |
| 5808 | @anchor{prologue instruction pattern} |
| 5809 | @item @samp{prologue} |
| 5810 | This pattern, if defined, emits RTL for entry to a function. The function |
| 5811 | entry is responsible for setting up the stack frame, initializing the frame |
| 5812 | pointer register, saving callee saved registers, etc. |
| 5813 | |
| 5814 | Using a prologue pattern is generally preferred over defining |
| 5815 | @code{TARGET_ASM_FUNCTION_PROLOGUE} to emit assembly code for the prologue. |
| 5816 | |
| 5817 | The @code{prologue} pattern is particularly useful for targets which perform |
| 5818 | instruction scheduling. |
| 5819 | |
| 5820 | @cindex @code{window_save} instruction pattern |
| 5821 | @anchor{window_save instruction pattern} |
| 5822 | @item @samp{window_save} |
| 5823 | This pattern, if defined, emits RTL for a register window save. It should |
| 5824 | be defined if the target machine has register windows but the window events |
| 5825 | are decoupled from calls to subroutines. The canonical example is the SPARC |
| 5826 | architecture. |
| 5827 | |
| 5828 | @cindex @code{epilogue} instruction pattern |
| 5829 | @anchor{epilogue instruction pattern} |
| 5830 | @item @samp{epilogue} |
| 5831 | This pattern emits RTL for exit from a function. The function |
| 5832 | exit is responsible for deallocating the stack frame, restoring callee saved |
| 5833 | registers and emitting the return instruction. |
| 5834 | |
| 5835 | Using an epilogue pattern is generally preferred over defining |
| 5836 | @code{TARGET_ASM_FUNCTION_EPILOGUE} to emit assembly code for the epilogue. |
| 5837 | |
| 5838 | The @code{epilogue} pattern is particularly useful for targets which perform |
| 5839 | instruction scheduling or which have delay slots for their return instruction. |
| 5840 | |
| 5841 | @cindex @code{sibcall_epilogue} instruction pattern |
| 5842 | @item @samp{sibcall_epilogue} |
| 5843 | This pattern, if defined, emits RTL for exit from a function without the final |
| 5844 | branch back to the calling function. This pattern will be emitted before any |
| 5845 | sibling call (aka tail call) sites. |
| 5846 | |
| 5847 | The @code{sibcall_epilogue} pattern must not clobber any arguments used for |
| 5848 | parameter passing or any stack slots for arguments passed to the current |
| 5849 | function. |
| 5850 | |
| 5851 | @cindex @code{trap} instruction pattern |
| 5852 | @item @samp{trap} |
| 5853 | This pattern, if defined, signals an error, typically by causing some |
| 5854 | kind of signal to be raised. Among other places, it is used by the Java |
| 5855 | front end to signal `invalid array index' exceptions. |
| 5856 | |
| 5857 | @cindex @code{ctrap@var{MM}4} instruction pattern |
| 5858 | @item @samp{ctrap@var{MM}4} |
| 5859 | Conditional trap instruction. Operand 0 is a piece of RTL which |
| 5860 | performs a comparison, and operands 1 and 2 are the arms of the |
| 5861 | comparison. Operand 3 is the trap code, an integer. |
| 5862 | |
| 5863 | A typical @code{ctrap} pattern looks like |
| 5864 | |
| 5865 | @smallexample |
| 5866 | (define_insn "ctrapsi4" |
| 5867 | [(trap_if (match_operator 0 "trap_operator" |
| 5868 | [(match_operand 1 "register_operand") |
| 5869 | (match_operand 2 "immediate_operand")]) |
| 5870 | (match_operand 3 "const_int_operand" "i"))] |
| 5871 | "" |
| 5872 | "@dots{}") |
| 5873 | @end smallexample |
| 5874 | |
| 5875 | @cindex @code{prefetch} instruction pattern |
| 5876 | @item @samp{prefetch} |
| 5877 | |
| 5878 | This pattern, if defined, emits code for a non-faulting data prefetch |
| 5879 | instruction. Operand 0 is the address of the memory to prefetch. Operand 1 |
| 5880 | is a constant 1 if the prefetch is preparing for a write to the memory |
| 5881 | address, or a constant 0 otherwise. Operand 2 is the expected degree of |
| 5882 | temporal locality of the data and is a value between 0 and 3, inclusive; 0 |
| 5883 | means that the data has no temporal locality, so it need not be left in the |
| 5884 | cache after the access; 3 means that the data has a high degree of temporal |
| 5885 | locality and should be left in all levels of cache possible; 1 and 2 mean, |
| 5886 | respectively, a low or moderate degree of temporal locality. |
| 5887 | |
| 5888 | Targets that do not support write prefetches or locality hints can ignore |
| 5889 | the values of operands 1 and 2. |
| 5890 | |
| 5891 | @cindex @code{blockage} instruction pattern |
| 5892 | @item @samp{blockage} |
| 5893 | |
| 5894 | This pattern defines a pseudo insn that prevents the instruction |
| 5895 | scheduler from moving instructions across the boundary defined by the |
| 5896 | blockage insn. Normally an UNSPEC_VOLATILE pattern. |
| 5897 | |
| 5898 | @cindex @code{memory_barrier} instruction pattern |
| 5899 | @item @samp{memory_barrier} |
| 5900 | |
| 5901 | If the target memory model is not fully synchronous, then this pattern |
| 5902 | should be defined to an instruction that orders both loads and stores |
| 5903 | before the instruction with respect to loads and stores after the instruction. |
| 5904 | This pattern has no operands. |
| 5905 | |
| 5906 | @cindex @code{sync_compare_and_swap@var{mode}} instruction pattern |
| 5907 | @item @samp{sync_compare_and_swap@var{mode}} |
| 5908 | |
| 5909 | This pattern, if defined, emits code for an atomic compare-and-swap |
| 5910 | operation. Operand 1 is the memory on which the atomic operation is |
| 5911 | performed. Operand 2 is the ``old'' value to be compared against the |
| 5912 | current contents of the memory location. Operand 3 is the ``new'' value |
| 5913 | to store in the memory if the compare succeeds. Operand 0 is the result |
| 5914 | of the operation; it should contain the contents of the memory |
| 5915 | before the operation. If the compare succeeds, this should obviously be |
| 5916 | a copy of operand 2. |
| 5917 | |
| 5918 | This pattern must show that both operand 0 and operand 1 are modified. |
| 5919 | |
| 5920 | This pattern must issue any memory barrier instructions such that all |
| 5921 | memory operations before the atomic operation occur before the atomic |
| 5922 | operation and all memory operations after the atomic operation occur |
| 5923 | after the atomic operation. |
| 5924 | |
| 5925 | For targets where the success or failure of the compare-and-swap |
| 5926 | operation is available via the status flags, it is possible to |
| 5927 | avoid a separate compare operation and issue the subsequent |
| 5928 | branch or store-flag operation immediately after the compare-and-swap. |
| 5929 | To this end, GCC will look for a @code{MODE_CC} set in the |
| 5930 | output of @code{sync_compare_and_swap@var{mode}}; if the machine |
| 5931 | description includes such a set, the target should also define special |
| 5932 | @code{cbranchcc4} and/or @code{cstorecc4} instructions. GCC will then |
| 5933 | be able to take the destination of the @code{MODE_CC} set and pass it |
| 5934 | to the @code{cbranchcc4} or @code{cstorecc4} pattern as the first |
| 5935 | operand of the comparison (the second will be @code{(const_int 0)}). |
| 5936 | |
| 5937 | For targets where the operating system may provide support for this |
| 5938 | operation via library calls, the @code{sync_compare_and_swap_optab} |
| 5939 | may be initialized to a function with the same interface as the |
| 5940 | @code{__sync_val_compare_and_swap_@var{n}} built-in. If the entire |
| 5941 | set of @var{__sync} builtins are supported via library calls, the |
| 5942 | target can initialize all of the optabs at once with |
| 5943 | @code{init_sync_libfuncs}. |
| 5944 | For the purposes of C++11 @code{std::atomic::is_lock_free}, it is |
| 5945 | assumed that these library calls do @emph{not} use any kind of |
| 5946 | interruptable locking. |
| 5947 | |
| 5948 | @cindex @code{sync_add@var{mode}} instruction pattern |
| 5949 | @cindex @code{sync_sub@var{mode}} instruction pattern |
| 5950 | @cindex @code{sync_ior@var{mode}} instruction pattern |
| 5951 | @cindex @code{sync_and@var{mode}} instruction pattern |
| 5952 | @cindex @code{sync_xor@var{mode}} instruction pattern |
| 5953 | @cindex @code{sync_nand@var{mode}} instruction pattern |
| 5954 | @item @samp{sync_add@var{mode}}, @samp{sync_sub@var{mode}} |
| 5955 | @itemx @samp{sync_ior@var{mode}}, @samp{sync_and@var{mode}} |
| 5956 | @itemx @samp{sync_xor@var{mode}}, @samp{sync_nand@var{mode}} |
| 5957 | |
| 5958 | These patterns emit code for an atomic operation on memory. |
| 5959 | Operand 0 is the memory on which the atomic operation is performed. |
| 5960 | Operand 1 is the second operand to the binary operator. |
| 5961 | |
| 5962 | This pattern must issue any memory barrier instructions such that all |
| 5963 | memory operations before the atomic operation occur before the atomic |
| 5964 | operation and all memory operations after the atomic operation occur |
| 5965 | after the atomic operation. |
| 5966 | |
| 5967 | If these patterns are not defined, the operation will be constructed |
| 5968 | from a compare-and-swap operation, if defined. |
| 5969 | |
| 5970 | @cindex @code{sync_old_add@var{mode}} instruction pattern |
| 5971 | @cindex @code{sync_old_sub@var{mode}} instruction pattern |
| 5972 | @cindex @code{sync_old_ior@var{mode}} instruction pattern |
| 5973 | @cindex @code{sync_old_and@var{mode}} instruction pattern |
| 5974 | @cindex @code{sync_old_xor@var{mode}} instruction pattern |
| 5975 | @cindex @code{sync_old_nand@var{mode}} instruction pattern |
| 5976 | @item @samp{sync_old_add@var{mode}}, @samp{sync_old_sub@var{mode}} |
| 5977 | @itemx @samp{sync_old_ior@var{mode}}, @samp{sync_old_and@var{mode}} |
| 5978 | @itemx @samp{sync_old_xor@var{mode}}, @samp{sync_old_nand@var{mode}} |
| 5979 | |
| 5980 | These patterns emit code for an atomic operation on memory, |
| 5981 | and return the value that the memory contained before the operation. |
| 5982 | Operand 0 is the result value, operand 1 is the memory on which the |
| 5983 | atomic operation is performed, and operand 2 is the second operand |
| 5984 | to the binary operator. |
| 5985 | |
| 5986 | This pattern must issue any memory barrier instructions such that all |
| 5987 | memory operations before the atomic operation occur before the atomic |
| 5988 | operation and all memory operations after the atomic operation occur |
| 5989 | after the atomic operation. |
| 5990 | |
| 5991 | If these patterns are not defined, the operation will be constructed |
| 5992 | from a compare-and-swap operation, if defined. |
| 5993 | |
| 5994 | @cindex @code{sync_new_add@var{mode}} instruction pattern |
| 5995 | @cindex @code{sync_new_sub@var{mode}} instruction pattern |
| 5996 | @cindex @code{sync_new_ior@var{mode}} instruction pattern |
| 5997 | @cindex @code{sync_new_and@var{mode}} instruction pattern |
| 5998 | @cindex @code{sync_new_xor@var{mode}} instruction pattern |
| 5999 | @cindex @code{sync_new_nand@var{mode}} instruction pattern |
| 6000 | @item @samp{sync_new_add@var{mode}}, @samp{sync_new_sub@var{mode}} |
| 6001 | @itemx @samp{sync_new_ior@var{mode}}, @samp{sync_new_and@var{mode}} |
| 6002 | @itemx @samp{sync_new_xor@var{mode}}, @samp{sync_new_nand@var{mode}} |
| 6003 | |
| 6004 | These patterns are like their @code{sync_old_@var{op}} counterparts, |
| 6005 | except that they return the value that exists in the memory location |
| 6006 | after the operation, rather than before the operation. |
| 6007 | |
| 6008 | @cindex @code{sync_lock_test_and_set@var{mode}} instruction pattern |
| 6009 | @item @samp{sync_lock_test_and_set@var{mode}} |
| 6010 | |
| 6011 | This pattern takes two forms, based on the capabilities of the target. |
| 6012 | In either case, operand 0 is the result of the operand, operand 1 is |
| 6013 | the memory on which the atomic operation is performed, and operand 2 |
| 6014 | is the value to set in the lock. |
| 6015 | |
| 6016 | In the ideal case, this operation is an atomic exchange operation, in |
| 6017 | which the previous value in memory operand is copied into the result |
| 6018 | operand, and the value operand is stored in the memory operand. |
| 6019 | |
| 6020 | For less capable targets, any value operand that is not the constant 1 |
| 6021 | should be rejected with @code{FAIL}. In this case the target may use |
| 6022 | an atomic test-and-set bit operation. The result operand should contain |
| 6023 | 1 if the bit was previously set and 0 if the bit was previously clear. |
| 6024 | The true contents of the memory operand are implementation defined. |
| 6025 | |
| 6026 | This pattern must issue any memory barrier instructions such that the |
| 6027 | pattern as a whole acts as an acquire barrier, that is all memory |
| 6028 | operations after the pattern do not occur until the lock is acquired. |
| 6029 | |
| 6030 | If this pattern is not defined, the operation will be constructed from |
| 6031 | a compare-and-swap operation, if defined. |
| 6032 | |
| 6033 | @cindex @code{sync_lock_release@var{mode}} instruction pattern |
| 6034 | @item @samp{sync_lock_release@var{mode}} |
| 6035 | |
| 6036 | This pattern, if defined, releases a lock set by |
| 6037 | @code{sync_lock_test_and_set@var{mode}}. Operand 0 is the memory |
| 6038 | that contains the lock; operand 1 is the value to store in the lock. |
| 6039 | |
| 6040 | If the target doesn't implement full semantics for |
| 6041 | @code{sync_lock_test_and_set@var{mode}}, any value operand which is not |
| 6042 | the constant 0 should be rejected with @code{FAIL}, and the true contents |
| 6043 | of the memory operand are implementation defined. |
| 6044 | |
| 6045 | This pattern must issue any memory barrier instructions such that the |
| 6046 | pattern as a whole acts as a release barrier, that is the lock is |
| 6047 | released only after all previous memory operations have completed. |
| 6048 | |
| 6049 | If this pattern is not defined, then a @code{memory_barrier} pattern |
| 6050 | will be emitted, followed by a store of the value to the memory operand. |
| 6051 | |
| 6052 | @cindex @code{atomic_compare_and_swap@var{mode}} instruction pattern |
| 6053 | @item @samp{atomic_compare_and_swap@var{mode}} |
| 6054 | This pattern, if defined, emits code for an atomic compare-and-swap |
| 6055 | operation with memory model semantics. Operand 2 is the memory on which |
| 6056 | the atomic operation is performed. Operand 0 is an output operand which |
| 6057 | is set to true or false based on whether the operation succeeded. Operand |
| 6058 | 1 is an output operand which is set to the contents of the memory before |
| 6059 | the operation was attempted. Operand 3 is the value that is expected to |
| 6060 | be in memory. Operand 4 is the value to put in memory if the expected |
| 6061 | value is found there. Operand 5 is set to 1 if this compare and swap is to |
| 6062 | be treated as a weak operation. Operand 6 is the memory model to be used |
| 6063 | if the operation is a success. Operand 7 is the memory model to be used |
| 6064 | if the operation fails. |
| 6065 | |
| 6066 | If memory referred to in operand 2 contains the value in operand 3, then |
| 6067 | operand 4 is stored in memory pointed to by operand 2 and fencing based on |
| 6068 | the memory model in operand 6 is issued. |
| 6069 | |
| 6070 | If memory referred to in operand 2 does not contain the value in operand 3, |
| 6071 | then fencing based on the memory model in operand 7 is issued. |
| 6072 | |
| 6073 | If a target does not support weak compare-and-swap operations, or the port |
| 6074 | elects not to implement weak operations, the argument in operand 5 can be |
| 6075 | ignored. Note a strong implementation must be provided. |
| 6076 | |
| 6077 | If this pattern is not provided, the @code{__atomic_compare_exchange} |
| 6078 | built-in functions will utilize the legacy @code{sync_compare_and_swap} |
| 6079 | pattern with an @code{__ATOMIC_SEQ_CST} memory model. |
| 6080 | |
| 6081 | @cindex @code{atomic_load@var{mode}} instruction pattern |
| 6082 | @item @samp{atomic_load@var{mode}} |
| 6083 | This pattern implements an atomic load operation with memory model |
| 6084 | semantics. Operand 1 is the memory address being loaded from. Operand 0 |
| 6085 | is the result of the load. Operand 2 is the memory model to be used for |
| 6086 | the load operation. |
| 6087 | |
| 6088 | If not present, the @code{__atomic_load} built-in function will either |
| 6089 | resort to a normal load with memory barriers, or a compare-and-swap |
| 6090 | operation if a normal load would not be atomic. |
| 6091 | |
| 6092 | @cindex @code{atomic_store@var{mode}} instruction pattern |
| 6093 | @item @samp{atomic_store@var{mode}} |
| 6094 | This pattern implements an atomic store operation with memory model |
| 6095 | semantics. Operand 0 is the memory address being stored to. Operand 1 |
| 6096 | is the value to be written. Operand 2 is the memory model to be used for |
| 6097 | the operation. |
| 6098 | |
| 6099 | If not present, the @code{__atomic_store} built-in function will attempt to |
| 6100 | perform a normal store and surround it with any required memory fences. If |
| 6101 | the store would not be atomic, then an @code{__atomic_exchange} is |
| 6102 | attempted with the result being ignored. |
| 6103 | |
| 6104 | @cindex @code{atomic_exchange@var{mode}} instruction pattern |
| 6105 | @item @samp{atomic_exchange@var{mode}} |
| 6106 | This pattern implements an atomic exchange operation with memory model |
| 6107 | semantics. Operand 1 is the memory location the operation is performed on. |
| 6108 | Operand 0 is an output operand which is set to the original value contained |
| 6109 | in the memory pointed to by operand 1. Operand 2 is the value to be |
| 6110 | stored. Operand 3 is the memory model to be used. |
| 6111 | |
| 6112 | If this pattern is not present, the built-in function |
| 6113 | @code{__atomic_exchange} will attempt to preform the operation with a |
| 6114 | compare and swap loop. |
| 6115 | |
| 6116 | @cindex @code{atomic_add@var{mode}} instruction pattern |
| 6117 | @cindex @code{atomic_sub@var{mode}} instruction pattern |
| 6118 | @cindex @code{atomic_or@var{mode}} instruction pattern |
| 6119 | @cindex @code{atomic_and@var{mode}} instruction pattern |
| 6120 | @cindex @code{atomic_xor@var{mode}} instruction pattern |
| 6121 | @cindex @code{atomic_nand@var{mode}} instruction pattern |
| 6122 | @item @samp{atomic_add@var{mode}}, @samp{atomic_sub@var{mode}} |
| 6123 | @itemx @samp{atomic_or@var{mode}}, @samp{atomic_and@var{mode}} |
| 6124 | @itemx @samp{atomic_xor@var{mode}}, @samp{atomic_nand@var{mode}} |
| 6125 | |
| 6126 | These patterns emit code for an atomic operation on memory with memory |
| 6127 | model semantics. Operand 0 is the memory on which the atomic operation is |
| 6128 | performed. Operand 1 is the second operand to the binary operator. |
| 6129 | Operand 2 is the memory model to be used by the operation. |
| 6130 | |
| 6131 | If these patterns are not defined, attempts will be made to use legacy |
| 6132 | @code{sync} patterns, or equivalent patterns which return a result. If |
| 6133 | none of these are available a compare-and-swap loop will be used. |
| 6134 | |
| 6135 | @cindex @code{atomic_fetch_add@var{mode}} instruction pattern |
| 6136 | @cindex @code{atomic_fetch_sub@var{mode}} instruction pattern |
| 6137 | @cindex @code{atomic_fetch_or@var{mode}} instruction pattern |
| 6138 | @cindex @code{atomic_fetch_and@var{mode}} instruction pattern |
| 6139 | @cindex @code{atomic_fetch_xor@var{mode}} instruction pattern |
| 6140 | @cindex @code{atomic_fetch_nand@var{mode}} instruction pattern |
| 6141 | @item @samp{atomic_fetch_add@var{mode}}, @samp{atomic_fetch_sub@var{mode}} |
| 6142 | @itemx @samp{atomic_fetch_or@var{mode}}, @samp{atomic_fetch_and@var{mode}} |
| 6143 | @itemx @samp{atomic_fetch_xor@var{mode}}, @samp{atomic_fetch_nand@var{mode}} |
| 6144 | |
| 6145 | These patterns emit code for an atomic operation on memory with memory |
| 6146 | model semantics, and return the original value. Operand 0 is an output |
| 6147 | operand which contains the value of the memory location before the |
| 6148 | operation was performed. Operand 1 is the memory on which the atomic |
| 6149 | operation is performed. Operand 2 is the second operand to the binary |
| 6150 | operator. Operand 3 is the memory model to be used by the operation. |
| 6151 | |
| 6152 | If these patterns are not defined, attempts will be made to use legacy |
| 6153 | @code{sync} patterns. If none of these are available a compare-and-swap |
| 6154 | loop will be used. |
| 6155 | |
| 6156 | @cindex @code{atomic_add_fetch@var{mode}} instruction pattern |
| 6157 | @cindex @code{atomic_sub_fetch@var{mode}} instruction pattern |
| 6158 | @cindex @code{atomic_or_fetch@var{mode}} instruction pattern |
| 6159 | @cindex @code{atomic_and_fetch@var{mode}} instruction pattern |
| 6160 | @cindex @code{atomic_xor_fetch@var{mode}} instruction pattern |
| 6161 | @cindex @code{atomic_nand_fetch@var{mode}} instruction pattern |
| 6162 | @item @samp{atomic_add_fetch@var{mode}}, @samp{atomic_sub_fetch@var{mode}} |
| 6163 | @itemx @samp{atomic_or_fetch@var{mode}}, @samp{atomic_and_fetch@var{mode}} |
| 6164 | @itemx @samp{atomic_xor_fetch@var{mode}}, @samp{atomic_nand_fetch@var{mode}} |
| 6165 | |
| 6166 | These patterns emit code for an atomic operation on memory with memory |
| 6167 | model semantics and return the result after the operation is performed. |
| 6168 | Operand 0 is an output operand which contains the value after the |
| 6169 | operation. Operand 1 is the memory on which the atomic operation is |
| 6170 | performed. Operand 2 is the second operand to the binary operator. |
| 6171 | Operand 3 is the memory model to be used by the operation. |
| 6172 | |
| 6173 | If these patterns are not defined, attempts will be made to use legacy |
| 6174 | @code{sync} patterns, or equivalent patterns which return the result before |
| 6175 | the operation followed by the arithmetic operation required to produce the |
| 6176 | result. If none of these are available a compare-and-swap loop will be |
| 6177 | used. |
| 6178 | |
| 6179 | @cindex @code{atomic_test_and_set} instruction pattern |
| 6180 | @item @samp{atomic_test_and_set} |
| 6181 | |
| 6182 | This pattern emits code for @code{__builtin_atomic_test_and_set}. |
| 6183 | Operand 0 is an output operand which is set to true if the previous |
| 6184 | previous contents of the byte was "set", and false otherwise. Operand 1 |
| 6185 | is the @code{QImode} memory to be modified. Operand 2 is the memory |
| 6186 | model to be used. |
| 6187 | |
| 6188 | The specific value that defines "set" is implementation defined, and |
| 6189 | is normally based on what is performed by the native atomic test and set |
| 6190 | instruction. |
| 6191 | |
| 6192 | @cindex @code{mem_thread_fence@var{mode}} instruction pattern |
| 6193 | @item @samp{mem_thread_fence@var{mode}} |
| 6194 | This pattern emits code required to implement a thread fence with |
| 6195 | memory model semantics. Operand 0 is the memory model to be used. |
| 6196 | |
| 6197 | If this pattern is not specified, all memory models except |
| 6198 | @code{__ATOMIC_RELAXED} will result in issuing a @code{sync_synchronize} |
| 6199 | barrier pattern. |
| 6200 | |
| 6201 | @cindex @code{mem_signal_fence@var{mode}} instruction pattern |
| 6202 | @item @samp{mem_signal_fence@var{mode}} |
| 6203 | This pattern emits code required to implement a signal fence with |
| 6204 | memory model semantics. Operand 0 is the memory model to be used. |
| 6205 | |
| 6206 | This pattern should impact the compiler optimizers the same way that |
| 6207 | mem_signal_fence does, but it does not need to issue any barrier |
| 6208 | instructions. |
| 6209 | |
| 6210 | If this pattern is not specified, all memory models except |
| 6211 | @code{__ATOMIC_RELAXED} will result in issuing a @code{sync_synchronize} |
| 6212 | barrier pattern. |
| 6213 | |
Bernhard Rosenkraenzer | d314d0e | 2012-10-17 01:40:06 +0159 | [diff] [blame] | 6214 | @cindex @code{get_thread_pointer@var{mode}} instruction pattern |
| 6215 | @cindex @code{set_thread_pointer@var{mode}} instruction pattern |
| 6216 | @item @samp{get_thread_pointer@var{mode}} |
| 6217 | @itemx @samp{set_thread_pointer@var{mode}} |
| 6218 | These patterns emit code that reads/sets the TLS thread pointer. Currently, |
| 6219 | these are only needed if the target needs to support the |
| 6220 | @code{__builtin_thread_pointer} and @code{__builtin_set_thread_pointer} |
| 6221 | builtins. |
| 6222 | |
| 6223 | The get/set patterns have a single output/input operand respectively, |
| 6224 | with @var{mode} intended to be @code{Pmode}. |
| 6225 | |
Bernhard Rosenkraenzer | c83ebe5 | 2012-09-18 21:38:03 +0159 | [diff] [blame] | 6226 | @cindex @code{stack_protect_set} instruction pattern |
| 6227 | @item @samp{stack_protect_set} |
| 6228 | |
| 6229 | This pattern, if defined, moves a @code{ptr_mode} value from the memory |
| 6230 | in operand 1 to the memory in operand 0 without leaving the value in |
| 6231 | a register afterward. This is to avoid leaking the value some place |
| 6232 | that an attacker might use to rewrite the stack guard slot after |
| 6233 | having clobbered it. |
| 6234 | |
| 6235 | If this pattern is not defined, then a plain move pattern is generated. |
| 6236 | |
| 6237 | @cindex @code{stack_protect_test} instruction pattern |
| 6238 | @item @samp{stack_protect_test} |
| 6239 | |
| 6240 | This pattern, if defined, compares a @code{ptr_mode} value from the |
| 6241 | memory in operand 1 with the memory in operand 0 without leaving the |
| 6242 | value in a register afterward and branches to operand 2 if the values |
| 6243 | were equal. |
| 6244 | |
| 6245 | If this pattern is not defined, then a plain compare pattern and |
| 6246 | conditional branch pattern is used. |
| 6247 | |
| 6248 | @cindex @code{clear_cache} instruction pattern |
| 6249 | @item @samp{clear_cache} |
| 6250 | |
| 6251 | This pattern, if defined, flushes the instruction cache for a region of |
| 6252 | memory. The region is bounded to by the Pmode pointers in operand 0 |
| 6253 | inclusive and operand 1 exclusive. |
| 6254 | |
| 6255 | If this pattern is not defined, a call to the library function |
| 6256 | @code{__clear_cache} is used. |
| 6257 | |
| 6258 | @end table |
| 6259 | |
| 6260 | @end ifset |
| 6261 | @c Each of the following nodes are wrapped in separate |
| 6262 | @c "@ifset INTERNALS" to work around memory limits for the default |
| 6263 | @c configuration in older tetex distributions. Known to not work: |
| 6264 | @c tetex-1.0.7, known to work: tetex-2.0.2. |
| 6265 | @ifset INTERNALS |
| 6266 | @node Pattern Ordering |
| 6267 | @section When the Order of Patterns Matters |
| 6268 | @cindex Pattern Ordering |
| 6269 | @cindex Ordering of Patterns |
| 6270 | |
| 6271 | Sometimes an insn can match more than one instruction pattern. Then the |
| 6272 | pattern that appears first in the machine description is the one used. |
| 6273 | Therefore, more specific patterns (patterns that will match fewer things) |
| 6274 | and faster instructions (those that will produce better code when they |
| 6275 | do match) should usually go first in the description. |
| 6276 | |
| 6277 | In some cases the effect of ordering the patterns can be used to hide |
| 6278 | a pattern when it is not valid. For example, the 68000 has an |
| 6279 | instruction for converting a fullword to floating point and another |
| 6280 | for converting a byte to floating point. An instruction converting |
| 6281 | an integer to floating point could match either one. We put the |
| 6282 | pattern to convert the fullword first to make sure that one will |
| 6283 | be used rather than the other. (Otherwise a large integer might |
| 6284 | be generated as a single-byte immediate quantity, which would not work.) |
| 6285 | Instead of using this pattern ordering it would be possible to make the |
| 6286 | pattern for convert-a-byte smart enough to deal properly with any |
| 6287 | constant value. |
| 6288 | |
| 6289 | @end ifset |
| 6290 | @ifset INTERNALS |
| 6291 | @node Dependent Patterns |
| 6292 | @section Interdependence of Patterns |
| 6293 | @cindex Dependent Patterns |
| 6294 | @cindex Interdependence of Patterns |
| 6295 | |
| 6296 | In some cases machines support instructions identical except for the |
| 6297 | machine mode of one or more operands. For example, there may be |
| 6298 | ``sign-extend halfword'' and ``sign-extend byte'' instructions whose |
| 6299 | patterns are |
| 6300 | |
| 6301 | @smallexample |
| 6302 | (set (match_operand:SI 0 @dots{}) |
| 6303 | (extend:SI (match_operand:HI 1 @dots{}))) |
| 6304 | |
| 6305 | (set (match_operand:SI 0 @dots{}) |
| 6306 | (extend:SI (match_operand:QI 1 @dots{}))) |
| 6307 | @end smallexample |
| 6308 | |
| 6309 | @noindent |
| 6310 | Constant integers do not specify a machine mode, so an instruction to |
| 6311 | extend a constant value could match either pattern. The pattern it |
| 6312 | actually will match is the one that appears first in the file. For correct |
| 6313 | results, this must be the one for the widest possible mode (@code{HImode}, |
| 6314 | here). If the pattern matches the @code{QImode} instruction, the results |
| 6315 | will be incorrect if the constant value does not actually fit that mode. |
| 6316 | |
| 6317 | Such instructions to extend constants are rarely generated because they are |
| 6318 | optimized away, but they do occasionally happen in nonoptimized |
| 6319 | compilations. |
| 6320 | |
| 6321 | If a constraint in a pattern allows a constant, the reload pass may |
| 6322 | replace a register with a constant permitted by the constraint in some |
| 6323 | cases. Similarly for memory references. Because of this substitution, |
| 6324 | you should not provide separate patterns for increment and decrement |
| 6325 | instructions. Instead, they should be generated from the same pattern |
| 6326 | that supports register-register add insns by examining the operands and |
| 6327 | generating the appropriate machine instruction. |
| 6328 | |
| 6329 | @end ifset |
| 6330 | @ifset INTERNALS |
| 6331 | @node Jump Patterns |
| 6332 | @section Defining Jump Instruction Patterns |
| 6333 | @cindex jump instruction patterns |
| 6334 | @cindex defining jump instruction patterns |
| 6335 | |
| 6336 | GCC does not assume anything about how the machine realizes jumps. |
| 6337 | The machine description should define a single pattern, usually |
| 6338 | a @code{define_expand}, which expands to all the required insns. |
| 6339 | |
| 6340 | Usually, this would be a comparison insn to set the condition code |
| 6341 | and a separate branch insn testing the condition code and branching |
| 6342 | or not according to its value. For many machines, however, |
| 6343 | separating compares and branches is limiting, which is why the |
| 6344 | more flexible approach with one @code{define_expand} is used in GCC. |
| 6345 | The machine description becomes clearer for architectures that |
| 6346 | have compare-and-branch instructions but no condition code. It also |
| 6347 | works better when different sets of comparison operators are supported |
| 6348 | by different kinds of conditional branches (e.g. integer vs. floating-point), |
| 6349 | or by conditional branches with respect to conditional stores. |
| 6350 | |
| 6351 | Two separate insns are always used if the machine description represents |
| 6352 | a condition code register using the legacy RTL expression @code{(cc0)}, |
| 6353 | and on most machines that use a separate condition code register |
| 6354 | (@pxref{Condition Code}). For machines that use @code{(cc0)}, in |
| 6355 | fact, the set and use of the condition code must be separate and |
| 6356 | adjacent@footnote{@code{note} insns can separate them, though.}, thus |
| 6357 | allowing flags in @code{cc_status} to be used (@pxref{Condition Code}) and |
| 6358 | so that the comparison and branch insns could be located from each other |
| 6359 | by using the functions @code{prev_cc0_setter} and @code{next_cc0_user}. |
| 6360 | |
| 6361 | Even in this case having a single entry point for conditional branches |
| 6362 | is advantageous, because it handles equally well the case where a single |
| 6363 | comparison instruction records the results of both signed and unsigned |
| 6364 | comparison of the given operands (with the branch insns coming in distinct |
| 6365 | signed and unsigned flavors) as in the x86 or SPARC, and the case where |
| 6366 | there are distinct signed and unsigned compare instructions and only |
| 6367 | one set of conditional branch instructions as in the PowerPC. |
| 6368 | |
| 6369 | @end ifset |
| 6370 | @ifset INTERNALS |
| 6371 | @node Looping Patterns |
| 6372 | @section Defining Looping Instruction Patterns |
| 6373 | @cindex looping instruction patterns |
| 6374 | @cindex defining looping instruction patterns |
| 6375 | |
| 6376 | Some machines have special jump instructions that can be utilized to |
| 6377 | make loops more efficient. A common example is the 68000 @samp{dbra} |
| 6378 | instruction which performs a decrement of a register and a branch if the |
| 6379 | result was greater than zero. Other machines, in particular digital |
| 6380 | signal processors (DSPs), have special block repeat instructions to |
| 6381 | provide low-overhead loop support. For example, the TI TMS320C3x/C4x |
| 6382 | DSPs have a block repeat instruction that loads special registers to |
| 6383 | mark the top and end of a loop and to count the number of loop |
| 6384 | iterations. This avoids the need for fetching and executing a |
| 6385 | @samp{dbra}-like instruction and avoids pipeline stalls associated with |
| 6386 | the jump. |
| 6387 | |
| 6388 | GCC has three special named patterns to support low overhead looping. |
| 6389 | They are @samp{decrement_and_branch_until_zero}, @samp{doloop_begin}, |
| 6390 | and @samp{doloop_end}. The first pattern, |
| 6391 | @samp{decrement_and_branch_until_zero}, is not emitted during RTL |
| 6392 | generation but may be emitted during the instruction combination phase. |
| 6393 | This requires the assistance of the loop optimizer, using information |
| 6394 | collected during strength reduction, to reverse a loop to count down to |
| 6395 | zero. Some targets also require the loop optimizer to add a |
| 6396 | @code{REG_NONNEG} note to indicate that the iteration count is always |
| 6397 | positive. This is needed if the target performs a signed loop |
| 6398 | termination test. For example, the 68000 uses a pattern similar to the |
| 6399 | following for its @code{dbra} instruction: |
| 6400 | |
| 6401 | @smallexample |
| 6402 | @group |
| 6403 | (define_insn "decrement_and_branch_until_zero" |
| 6404 | [(set (pc) |
| 6405 | (if_then_else |
| 6406 | (ge (plus:SI (match_operand:SI 0 "general_operand" "+d*am") |
| 6407 | (const_int -1)) |
| 6408 | (const_int 0)) |
| 6409 | (label_ref (match_operand 1 "" "")) |
| 6410 | (pc))) |
| 6411 | (set (match_dup 0) |
| 6412 | (plus:SI (match_dup 0) |
| 6413 | (const_int -1)))] |
| 6414 | "find_reg_note (insn, REG_NONNEG, 0)" |
| 6415 | "@dots{}") |
| 6416 | @end group |
| 6417 | @end smallexample |
| 6418 | |
| 6419 | Note that since the insn is both a jump insn and has an output, it must |
| 6420 | deal with its own reloads, hence the `m' constraints. Also note that |
| 6421 | since this insn is generated by the instruction combination phase |
| 6422 | combining two sequential insns together into an implicit parallel insn, |
| 6423 | the iteration counter needs to be biased by the same amount as the |
| 6424 | decrement operation, in this case @minus{}1. Note that the following similar |
| 6425 | pattern will not be matched by the combiner. |
| 6426 | |
| 6427 | @smallexample |
| 6428 | @group |
| 6429 | (define_insn "decrement_and_branch_until_zero" |
| 6430 | [(set (pc) |
| 6431 | (if_then_else |
| 6432 | (ge (match_operand:SI 0 "general_operand" "+d*am") |
| 6433 | (const_int 1)) |
| 6434 | (label_ref (match_operand 1 "" "")) |
| 6435 | (pc))) |
| 6436 | (set (match_dup 0) |
| 6437 | (plus:SI (match_dup 0) |
| 6438 | (const_int -1)))] |
| 6439 | "find_reg_note (insn, REG_NONNEG, 0)" |
| 6440 | "@dots{}") |
| 6441 | @end group |
| 6442 | @end smallexample |
| 6443 | |
| 6444 | The other two special looping patterns, @samp{doloop_begin} and |
| 6445 | @samp{doloop_end}, are emitted by the loop optimizer for certain |
| 6446 | well-behaved loops with a finite number of loop iterations using |
| 6447 | information collected during strength reduction. |
| 6448 | |
| 6449 | The @samp{doloop_end} pattern describes the actual looping instruction |
| 6450 | (or the implicit looping operation) and the @samp{doloop_begin} pattern |
| 6451 | is an optional companion pattern that can be used for initialization |
| 6452 | needed for some low-overhead looping instructions. |
| 6453 | |
| 6454 | Note that some machines require the actual looping instruction to be |
| 6455 | emitted at the top of the loop (e.g., the TMS320C3x/C4x DSPs). Emitting |
| 6456 | the true RTL for a looping instruction at the top of the loop can cause |
| 6457 | problems with flow analysis. So instead, a dummy @code{doloop} insn is |
| 6458 | emitted at the end of the loop. The machine dependent reorg pass checks |
| 6459 | for the presence of this @code{doloop} insn and then searches back to |
| 6460 | the top of the loop, where it inserts the true looping insn (provided |
| 6461 | there are no instructions in the loop which would cause problems). Any |
| 6462 | additional labels can be emitted at this point. In addition, if the |
| 6463 | desired special iteration counter register was not allocated, this |
| 6464 | machine dependent reorg pass could emit a traditional compare and jump |
| 6465 | instruction pair. |
| 6466 | |
| 6467 | The essential difference between the |
| 6468 | @samp{decrement_and_branch_until_zero} and the @samp{doloop_end} |
| 6469 | patterns is that the loop optimizer allocates an additional pseudo |
| 6470 | register for the latter as an iteration counter. This pseudo register |
| 6471 | cannot be used within the loop (i.e., general induction variables cannot |
| 6472 | be derived from it), however, in many cases the loop induction variable |
| 6473 | may become redundant and removed by the flow pass. |
| 6474 | |
| 6475 | |
| 6476 | @end ifset |
| 6477 | @ifset INTERNALS |
| 6478 | @node Insn Canonicalizations |
| 6479 | @section Canonicalization of Instructions |
| 6480 | @cindex canonicalization of instructions |
| 6481 | @cindex insn canonicalization |
| 6482 | |
| 6483 | There are often cases where multiple RTL expressions could represent an |
| 6484 | operation performed by a single machine instruction. This situation is |
| 6485 | most commonly encountered with logical, branch, and multiply-accumulate |
| 6486 | instructions. In such cases, the compiler attempts to convert these |
| 6487 | multiple RTL expressions into a single canonical form to reduce the |
| 6488 | number of insn patterns required. |
| 6489 | |
| 6490 | In addition to algebraic simplifications, following canonicalizations |
| 6491 | are performed: |
| 6492 | |
| 6493 | @itemize @bullet |
| 6494 | @item |
| 6495 | For commutative and comparison operators, a constant is always made the |
| 6496 | second operand. If a machine only supports a constant as the second |
| 6497 | operand, only patterns that match a constant in the second operand need |
| 6498 | be supplied. |
| 6499 | |
| 6500 | @item |
| 6501 | For associative operators, a sequence of operators will always chain |
| 6502 | to the left; for instance, only the left operand of an integer @code{plus} |
| 6503 | can itself be a @code{plus}. @code{and}, @code{ior}, @code{xor}, |
| 6504 | @code{plus}, @code{mult}, @code{smin}, @code{smax}, @code{umin}, and |
| 6505 | @code{umax} are associative when applied to integers, and sometimes to |
| 6506 | floating-point. |
| 6507 | |
| 6508 | @item |
| 6509 | @cindex @code{neg}, canonicalization of |
| 6510 | @cindex @code{not}, canonicalization of |
| 6511 | @cindex @code{mult}, canonicalization of |
| 6512 | @cindex @code{plus}, canonicalization of |
| 6513 | @cindex @code{minus}, canonicalization of |
| 6514 | For these operators, if only one operand is a @code{neg}, @code{not}, |
| 6515 | @code{mult}, @code{plus}, or @code{minus} expression, it will be the |
| 6516 | first operand. |
| 6517 | |
| 6518 | @item |
| 6519 | In combinations of @code{neg}, @code{mult}, @code{plus}, and |
| 6520 | @code{minus}, the @code{neg} operations (if any) will be moved inside |
| 6521 | the operations as far as possible. For instance, |
| 6522 | @code{(neg (mult A B))} is canonicalized as @code{(mult (neg A) B)}, but |
| 6523 | @code{(plus (mult (neg B) C) A)} is canonicalized as |
| 6524 | @code{(minus A (mult B C))}. |
| 6525 | |
| 6526 | @cindex @code{compare}, canonicalization of |
| 6527 | @item |
| 6528 | For the @code{compare} operator, a constant is always the second operand |
| 6529 | if the first argument is a condition code register or @code{(cc0)}. |
| 6530 | |
| 6531 | @item |
| 6532 | An operand of @code{neg}, @code{not}, @code{mult}, @code{plus}, or |
| 6533 | @code{minus} is made the first operand under the same conditions as |
| 6534 | above. |
| 6535 | |
| 6536 | @item |
| 6537 | @code{(ltu (plus @var{a} @var{b}) @var{b})} is converted to |
| 6538 | @code{(ltu (plus @var{a} @var{b}) @var{a})}. Likewise with @code{geu} instead |
| 6539 | of @code{ltu}. |
| 6540 | |
| 6541 | @item |
| 6542 | @code{(minus @var{x} (const_int @var{n}))} is converted to |
| 6543 | @code{(plus @var{x} (const_int @var{-n}))}. |
| 6544 | |
| 6545 | @item |
| 6546 | Within address computations (i.e., inside @code{mem}), a left shift is |
| 6547 | converted into the appropriate multiplication by a power of two. |
| 6548 | |
| 6549 | @cindex @code{ior}, canonicalization of |
| 6550 | @cindex @code{and}, canonicalization of |
| 6551 | @cindex De Morgan's law |
| 6552 | @item |
| 6553 | De Morgan's Law is used to move bitwise negation inside a bitwise |
| 6554 | logical-and or logical-or operation. If this results in only one |
| 6555 | operand being a @code{not} expression, it will be the first one. |
| 6556 | |
| 6557 | A machine that has an instruction that performs a bitwise logical-and of one |
| 6558 | operand with the bitwise negation of the other should specify the pattern |
| 6559 | for that instruction as |
| 6560 | |
| 6561 | @smallexample |
| 6562 | (define_insn "" |
| 6563 | [(set (match_operand:@var{m} 0 @dots{}) |
| 6564 | (and:@var{m} (not:@var{m} (match_operand:@var{m} 1 @dots{})) |
| 6565 | (match_operand:@var{m} 2 @dots{})))] |
| 6566 | "@dots{}" |
| 6567 | "@dots{}") |
| 6568 | @end smallexample |
| 6569 | |
| 6570 | @noindent |
| 6571 | Similarly, a pattern for a ``NAND'' instruction should be written |
| 6572 | |
| 6573 | @smallexample |
| 6574 | (define_insn "" |
| 6575 | [(set (match_operand:@var{m} 0 @dots{}) |
| 6576 | (ior:@var{m} (not:@var{m} (match_operand:@var{m} 1 @dots{})) |
| 6577 | (not:@var{m} (match_operand:@var{m} 2 @dots{}))))] |
| 6578 | "@dots{}" |
| 6579 | "@dots{}") |
| 6580 | @end smallexample |
| 6581 | |
| 6582 | In both cases, it is not necessary to include patterns for the many |
| 6583 | logically equivalent RTL expressions. |
| 6584 | |
| 6585 | @cindex @code{xor}, canonicalization of |
| 6586 | @item |
| 6587 | The only possible RTL expressions involving both bitwise exclusive-or |
| 6588 | and bitwise negation are @code{(xor:@var{m} @var{x} @var{y})} |
| 6589 | and @code{(not:@var{m} (xor:@var{m} @var{x} @var{y}))}. |
| 6590 | |
| 6591 | @item |
| 6592 | The sum of three items, one of which is a constant, will only appear in |
| 6593 | the form |
| 6594 | |
| 6595 | @smallexample |
| 6596 | (plus:@var{m} (plus:@var{m} @var{x} @var{y}) @var{constant}) |
| 6597 | @end smallexample |
| 6598 | |
| 6599 | @cindex @code{zero_extract}, canonicalization of |
| 6600 | @cindex @code{sign_extract}, canonicalization of |
| 6601 | @item |
| 6602 | Equality comparisons of a group of bits (usually a single bit) with zero |
| 6603 | will be written using @code{zero_extract} rather than the equivalent |
| 6604 | @code{and} or @code{sign_extract} operations. |
| 6605 | |
| 6606 | @cindex @code{mult}, canonicalization of |
| 6607 | @item |
| 6608 | @code{(sign_extend:@var{m1} (mult:@var{m2} (sign_extend:@var{m2} @var{x}) |
| 6609 | (sign_extend:@var{m2} @var{y})))} is converted to @code{(mult:@var{m1} |
| 6610 | (sign_extend:@var{m1} @var{x}) (sign_extend:@var{m1} @var{y}))}, and likewise |
| 6611 | for @code{zero_extend}. |
| 6612 | |
| 6613 | @item |
| 6614 | @code{(sign_extend:@var{m1} (mult:@var{m2} (ashiftrt:@var{m2} |
| 6615 | @var{x} @var{s}) (sign_extend:@var{m2} @var{y})))} is converted |
| 6616 | to @code{(mult:@var{m1} (sign_extend:@var{m1} (ashiftrt:@var{m2} |
| 6617 | @var{x} @var{s})) (sign_extend:@var{m1} @var{y}))}, and likewise for |
| 6618 | patterns using @code{zero_extend} and @code{lshiftrt}. If the second |
| 6619 | operand of @code{mult} is also a shift, then that is extended also. |
| 6620 | This transformation is only applied when it can be proven that the |
| 6621 | original operation had sufficient precision to prevent overflow. |
| 6622 | |
| 6623 | @end itemize |
| 6624 | |
| 6625 | Further canonicalization rules are defined in the function |
| 6626 | @code{commutative_operand_precedence} in @file{gcc/rtlanal.c}. |
| 6627 | |
| 6628 | @end ifset |
| 6629 | @ifset INTERNALS |
| 6630 | @node Expander Definitions |
| 6631 | @section Defining RTL Sequences for Code Generation |
| 6632 | @cindex expander definitions |
| 6633 | @cindex code generation RTL sequences |
| 6634 | @cindex defining RTL sequences for code generation |
| 6635 | |
| 6636 | On some target machines, some standard pattern names for RTL generation |
| 6637 | cannot be handled with single insn, but a sequence of RTL insns can |
| 6638 | represent them. For these target machines, you can write a |
| 6639 | @code{define_expand} to specify how to generate the sequence of RTL@. |
| 6640 | |
| 6641 | @findex define_expand |
| 6642 | A @code{define_expand} is an RTL expression that looks almost like a |
| 6643 | @code{define_insn}; but, unlike the latter, a @code{define_expand} is used |
| 6644 | only for RTL generation and it can produce more than one RTL insn. |
| 6645 | |
| 6646 | A @code{define_expand} RTX has four operands: |
| 6647 | |
| 6648 | @itemize @bullet |
| 6649 | @item |
| 6650 | The name. Each @code{define_expand} must have a name, since the only |
| 6651 | use for it is to refer to it by name. |
| 6652 | |
| 6653 | @item |
| 6654 | The RTL template. This is a vector of RTL expressions representing |
| 6655 | a sequence of separate instructions. Unlike @code{define_insn}, there |
| 6656 | is no implicit surrounding @code{PARALLEL}. |
| 6657 | |
| 6658 | @item |
| 6659 | The condition, a string containing a C expression. This expression is |
| 6660 | used to express how the availability of this pattern depends on |
| 6661 | subclasses of target machine, selected by command-line options when GCC |
| 6662 | is run. This is just like the condition of a @code{define_insn} that |
| 6663 | has a standard name. Therefore, the condition (if present) may not |
| 6664 | depend on the data in the insn being matched, but only the |
| 6665 | target-machine-type flags. The compiler needs to test these conditions |
| 6666 | during initialization in order to learn exactly which named instructions |
| 6667 | are available in a particular run. |
| 6668 | |
| 6669 | @item |
| 6670 | The preparation statements, a string containing zero or more C |
| 6671 | statements which are to be executed before RTL code is generated from |
| 6672 | the RTL template. |
| 6673 | |
| 6674 | Usually these statements prepare temporary registers for use as |
| 6675 | internal operands in the RTL template, but they can also generate RTL |
| 6676 | insns directly by calling routines such as @code{emit_insn}, etc. |
| 6677 | Any such insns precede the ones that come from the RTL template. |
| 6678 | @end itemize |
| 6679 | |
| 6680 | Every RTL insn emitted by a @code{define_expand} must match some |
| 6681 | @code{define_insn} in the machine description. Otherwise, the compiler |
| 6682 | will crash when trying to generate code for the insn or trying to optimize |
| 6683 | it. |
| 6684 | |
| 6685 | The RTL template, in addition to controlling generation of RTL insns, |
| 6686 | also describes the operands that need to be specified when this pattern |
| 6687 | is used. In particular, it gives a predicate for each operand. |
| 6688 | |
| 6689 | A true operand, which needs to be specified in order to generate RTL from |
| 6690 | the pattern, should be described with a @code{match_operand} in its first |
| 6691 | occurrence in the RTL template. This enters information on the operand's |
| 6692 | predicate into the tables that record such things. GCC uses the |
| 6693 | information to preload the operand into a register if that is required for |
| 6694 | valid RTL code. If the operand is referred to more than once, subsequent |
| 6695 | references should use @code{match_dup}. |
| 6696 | |
| 6697 | The RTL template may also refer to internal ``operands'' which are |
| 6698 | temporary registers or labels used only within the sequence made by the |
| 6699 | @code{define_expand}. Internal operands are substituted into the RTL |
| 6700 | template with @code{match_dup}, never with @code{match_operand}. The |
| 6701 | values of the internal operands are not passed in as arguments by the |
| 6702 | compiler when it requests use of this pattern. Instead, they are computed |
| 6703 | within the pattern, in the preparation statements. These statements |
| 6704 | compute the values and store them into the appropriate elements of |
| 6705 | @code{operands} so that @code{match_dup} can find them. |
| 6706 | |
| 6707 | There are two special macros defined for use in the preparation statements: |
| 6708 | @code{DONE} and @code{FAIL}. Use them with a following semicolon, |
| 6709 | as a statement. |
| 6710 | |
| 6711 | @table @code |
| 6712 | |
| 6713 | @findex DONE |
| 6714 | @item DONE |
| 6715 | Use the @code{DONE} macro to end RTL generation for the pattern. The |
| 6716 | only RTL insns resulting from the pattern on this occasion will be |
| 6717 | those already emitted by explicit calls to @code{emit_insn} within the |
| 6718 | preparation statements; the RTL template will not be generated. |
| 6719 | |
| 6720 | @findex FAIL |
| 6721 | @item FAIL |
| 6722 | Make the pattern fail on this occasion. When a pattern fails, it means |
| 6723 | that the pattern was not truly available. The calling routines in the |
| 6724 | compiler will try other strategies for code generation using other patterns. |
| 6725 | |
| 6726 | Failure is currently supported only for binary (addition, multiplication, |
| 6727 | shifting, etc.) and bit-field (@code{extv}, @code{extzv}, and @code{insv}) |
| 6728 | operations. |
| 6729 | @end table |
| 6730 | |
| 6731 | If the preparation falls through (invokes neither @code{DONE} nor |
| 6732 | @code{FAIL}), then the @code{define_expand} acts like a |
| 6733 | @code{define_insn} in that the RTL template is used to generate the |
| 6734 | insn. |
| 6735 | |
| 6736 | The RTL template is not used for matching, only for generating the |
| 6737 | initial insn list. If the preparation statement always invokes |
| 6738 | @code{DONE} or @code{FAIL}, the RTL template may be reduced to a simple |
| 6739 | list of operands, such as this example: |
| 6740 | |
| 6741 | @smallexample |
| 6742 | @group |
| 6743 | (define_expand "addsi3" |
| 6744 | [(match_operand:SI 0 "register_operand" "") |
| 6745 | (match_operand:SI 1 "register_operand" "") |
| 6746 | (match_operand:SI 2 "register_operand" "")] |
| 6747 | @end group |
| 6748 | @group |
| 6749 | "" |
| 6750 | " |
| 6751 | @{ |
| 6752 | handle_add (operands[0], operands[1], operands[2]); |
| 6753 | DONE; |
| 6754 | @}") |
| 6755 | @end group |
| 6756 | @end smallexample |
| 6757 | |
| 6758 | Here is an example, the definition of left-shift for the SPUR chip: |
| 6759 | |
| 6760 | @smallexample |
| 6761 | @group |
| 6762 | (define_expand "ashlsi3" |
| 6763 | [(set (match_operand:SI 0 "register_operand" "") |
| 6764 | (ashift:SI |
| 6765 | @end group |
| 6766 | @group |
| 6767 | (match_operand:SI 1 "register_operand" "") |
| 6768 | (match_operand:SI 2 "nonmemory_operand" "")))] |
| 6769 | "" |
| 6770 | " |
| 6771 | @end group |
| 6772 | @end smallexample |
| 6773 | |
| 6774 | @smallexample |
| 6775 | @group |
| 6776 | @{ |
| 6777 | if (GET_CODE (operands[2]) != CONST_INT |
| 6778 | || (unsigned) INTVAL (operands[2]) > 3) |
| 6779 | FAIL; |
| 6780 | @}") |
| 6781 | @end group |
| 6782 | @end smallexample |
| 6783 | |
| 6784 | @noindent |
| 6785 | This example uses @code{define_expand} so that it can generate an RTL insn |
| 6786 | for shifting when the shift-count is in the supported range of 0 to 3 but |
| 6787 | fail in other cases where machine insns aren't available. When it fails, |
| 6788 | the compiler tries another strategy using different patterns (such as, a |
| 6789 | library call). |
| 6790 | |
| 6791 | If the compiler were able to handle nontrivial condition-strings in |
| 6792 | patterns with names, then it would be possible to use a |
| 6793 | @code{define_insn} in that case. Here is another case (zero-extension |
| 6794 | on the 68000) which makes more use of the power of @code{define_expand}: |
| 6795 | |
| 6796 | @smallexample |
| 6797 | (define_expand "zero_extendhisi2" |
| 6798 | [(set (match_operand:SI 0 "general_operand" "") |
| 6799 | (const_int 0)) |
| 6800 | (set (strict_low_part |
| 6801 | (subreg:HI |
| 6802 | (match_dup 0) |
| 6803 | 0)) |
| 6804 | (match_operand:HI 1 "general_operand" ""))] |
| 6805 | "" |
| 6806 | "operands[1] = make_safe_from (operands[1], operands[0]);") |
| 6807 | @end smallexample |
| 6808 | |
| 6809 | @noindent |
| 6810 | @findex make_safe_from |
| 6811 | Here two RTL insns are generated, one to clear the entire output operand |
| 6812 | and the other to copy the input operand into its low half. This sequence |
| 6813 | is incorrect if the input operand refers to [the old value of] the output |
| 6814 | operand, so the preparation statement makes sure this isn't so. The |
| 6815 | function @code{make_safe_from} copies the @code{operands[1]} into a |
| 6816 | temporary register if it refers to @code{operands[0]}. It does this |
| 6817 | by emitting another RTL insn. |
| 6818 | |
| 6819 | Finally, a third example shows the use of an internal operand. |
| 6820 | Zero-extension on the SPUR chip is done by @code{and}-ing the result |
| 6821 | against a halfword mask. But this mask cannot be represented by a |
| 6822 | @code{const_int} because the constant value is too large to be legitimate |
| 6823 | on this machine. So it must be copied into a register with |
| 6824 | @code{force_reg} and then the register used in the @code{and}. |
| 6825 | |
| 6826 | @smallexample |
| 6827 | (define_expand "zero_extendhisi2" |
| 6828 | [(set (match_operand:SI 0 "register_operand" "") |
| 6829 | (and:SI (subreg:SI |
| 6830 | (match_operand:HI 1 "register_operand" "") |
| 6831 | 0) |
| 6832 | (match_dup 2)))] |
| 6833 | "" |
| 6834 | "operands[2] |
| 6835 | = force_reg (SImode, GEN_INT (65535)); ") |
| 6836 | @end smallexample |
| 6837 | |
| 6838 | @emph{Note:} If the @code{define_expand} is used to serve a |
| 6839 | standard binary or unary arithmetic operation or a bit-field operation, |
| 6840 | then the last insn it generates must not be a @code{code_label}, |
| 6841 | @code{barrier} or @code{note}. It must be an @code{insn}, |
| 6842 | @code{jump_insn} or @code{call_insn}. If you don't need a real insn |
| 6843 | at the end, emit an insn to copy the result of the operation into |
| 6844 | itself. Such an insn will generate no code, but it can avoid problems |
| 6845 | in the compiler. |
| 6846 | |
| 6847 | @end ifset |
| 6848 | @ifset INTERNALS |
| 6849 | @node Insn Splitting |
| 6850 | @section Defining How to Split Instructions |
| 6851 | @cindex insn splitting |
| 6852 | @cindex instruction splitting |
| 6853 | @cindex splitting instructions |
| 6854 | |
| 6855 | There are two cases where you should specify how to split a pattern |
| 6856 | into multiple insns. On machines that have instructions requiring |
| 6857 | delay slots (@pxref{Delay Slots}) or that have instructions whose |
| 6858 | output is not available for multiple cycles (@pxref{Processor pipeline |
| 6859 | description}), the compiler phases that optimize these cases need to |
| 6860 | be able to move insns into one-instruction delay slots. However, some |
| 6861 | insns may generate more than one machine instruction. These insns |
| 6862 | cannot be placed into a delay slot. |
| 6863 | |
| 6864 | Often you can rewrite the single insn as a list of individual insns, |
| 6865 | each corresponding to one machine instruction. The disadvantage of |
| 6866 | doing so is that it will cause the compilation to be slower and require |
| 6867 | more space. If the resulting insns are too complex, it may also |
| 6868 | suppress some optimizations. The compiler splits the insn if there is a |
| 6869 | reason to believe that it might improve instruction or delay slot |
| 6870 | scheduling. |
| 6871 | |
| 6872 | The insn combiner phase also splits putative insns. If three insns are |
| 6873 | merged into one insn with a complex expression that cannot be matched by |
| 6874 | some @code{define_insn} pattern, the combiner phase attempts to split |
| 6875 | the complex pattern into two insns that are recognized. Usually it can |
| 6876 | break the complex pattern into two patterns by splitting out some |
| 6877 | subexpression. However, in some other cases, such as performing an |
| 6878 | addition of a large constant in two insns on a RISC machine, the way to |
| 6879 | split the addition into two insns is machine-dependent. |
| 6880 | |
| 6881 | @findex define_split |
| 6882 | The @code{define_split} definition tells the compiler how to split a |
| 6883 | complex insn into several simpler insns. It looks like this: |
| 6884 | |
| 6885 | @smallexample |
| 6886 | (define_split |
| 6887 | [@var{insn-pattern}] |
| 6888 | "@var{condition}" |
| 6889 | [@var{new-insn-pattern-1} |
| 6890 | @var{new-insn-pattern-2} |
| 6891 | @dots{}] |
| 6892 | "@var{preparation-statements}") |
| 6893 | @end smallexample |
| 6894 | |
| 6895 | @var{insn-pattern} is a pattern that needs to be split and |
| 6896 | @var{condition} is the final condition to be tested, as in a |
| 6897 | @code{define_insn}. When an insn matching @var{insn-pattern} and |
| 6898 | satisfying @var{condition} is found, it is replaced in the insn list |
| 6899 | with the insns given by @var{new-insn-pattern-1}, |
| 6900 | @var{new-insn-pattern-2}, etc. |
| 6901 | |
| 6902 | The @var{preparation-statements} are similar to those statements that |
| 6903 | are specified for @code{define_expand} (@pxref{Expander Definitions}) |
| 6904 | and are executed before the new RTL is generated to prepare for the |
| 6905 | generated code or emit some insns whose pattern is not fixed. Unlike |
| 6906 | those in @code{define_expand}, however, these statements must not |
| 6907 | generate any new pseudo-registers. Once reload has completed, they also |
| 6908 | must not allocate any space in the stack frame. |
| 6909 | |
| 6910 | Patterns are matched against @var{insn-pattern} in two different |
| 6911 | circumstances. If an insn needs to be split for delay slot scheduling |
| 6912 | or insn scheduling, the insn is already known to be valid, which means |
| 6913 | that it must have been matched by some @code{define_insn} and, if |
| 6914 | @code{reload_completed} is nonzero, is known to satisfy the constraints |
| 6915 | of that @code{define_insn}. In that case, the new insn patterns must |
| 6916 | also be insns that are matched by some @code{define_insn} and, if |
| 6917 | @code{reload_completed} is nonzero, must also satisfy the constraints |
| 6918 | of those definitions. |
| 6919 | |
| 6920 | As an example of this usage of @code{define_split}, consider the following |
| 6921 | example from @file{a29k.md}, which splits a @code{sign_extend} from |
| 6922 | @code{HImode} to @code{SImode} into a pair of shift insns: |
| 6923 | |
| 6924 | @smallexample |
| 6925 | (define_split |
| 6926 | [(set (match_operand:SI 0 "gen_reg_operand" "") |
| 6927 | (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))] |
| 6928 | "" |
| 6929 | [(set (match_dup 0) |
| 6930 | (ashift:SI (match_dup 1) |
| 6931 | (const_int 16))) |
| 6932 | (set (match_dup 0) |
| 6933 | (ashiftrt:SI (match_dup 0) |
| 6934 | (const_int 16)))] |
| 6935 | " |
| 6936 | @{ operands[1] = gen_lowpart (SImode, operands[1]); @}") |
| 6937 | @end smallexample |
| 6938 | |
| 6939 | When the combiner phase tries to split an insn pattern, it is always the |
| 6940 | case that the pattern is @emph{not} matched by any @code{define_insn}. |
| 6941 | The combiner pass first tries to split a single @code{set} expression |
| 6942 | and then the same @code{set} expression inside a @code{parallel}, but |
| 6943 | followed by a @code{clobber} of a pseudo-reg to use as a scratch |
| 6944 | register. In these cases, the combiner expects exactly two new insn |
| 6945 | patterns to be generated. It will verify that these patterns match some |
| 6946 | @code{define_insn} definitions, so you need not do this test in the |
| 6947 | @code{define_split} (of course, there is no point in writing a |
| 6948 | @code{define_split} that will never produce insns that match). |
| 6949 | |
| 6950 | Here is an example of this use of @code{define_split}, taken from |
| 6951 | @file{rs6000.md}: |
| 6952 | |
| 6953 | @smallexample |
| 6954 | (define_split |
| 6955 | [(set (match_operand:SI 0 "gen_reg_operand" "") |
| 6956 | (plus:SI (match_operand:SI 1 "gen_reg_operand" "") |
| 6957 | (match_operand:SI 2 "non_add_cint_operand" "")))] |
| 6958 | "" |
| 6959 | [(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 3))) |
| 6960 | (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 4)))] |
| 6961 | " |
| 6962 | @{ |
| 6963 | int low = INTVAL (operands[2]) & 0xffff; |
| 6964 | int high = (unsigned) INTVAL (operands[2]) >> 16; |
| 6965 | |
| 6966 | if (low & 0x8000) |
| 6967 | high++, low |= 0xffff0000; |
| 6968 | |
| 6969 | operands[3] = GEN_INT (high << 16); |
| 6970 | operands[4] = GEN_INT (low); |
| 6971 | @}") |
| 6972 | @end smallexample |
| 6973 | |
| 6974 | Here the predicate @code{non_add_cint_operand} matches any |
| 6975 | @code{const_int} that is @emph{not} a valid operand of a single add |
| 6976 | insn. The add with the smaller displacement is written so that it |
| 6977 | can be substituted into the address of a subsequent operation. |
| 6978 | |
| 6979 | An example that uses a scratch register, from the same file, generates |
| 6980 | an equality comparison of a register and a large constant: |
| 6981 | |
| 6982 | @smallexample |
| 6983 | (define_split |
| 6984 | [(set (match_operand:CC 0 "cc_reg_operand" "") |
| 6985 | (compare:CC (match_operand:SI 1 "gen_reg_operand" "") |
| 6986 | (match_operand:SI 2 "non_short_cint_operand" ""))) |
| 6987 | (clobber (match_operand:SI 3 "gen_reg_operand" ""))] |
| 6988 | "find_single_use (operands[0], insn, 0) |
| 6989 | && (GET_CODE (*find_single_use (operands[0], insn, 0)) == EQ |
| 6990 | || GET_CODE (*find_single_use (operands[0], insn, 0)) == NE)" |
| 6991 | [(set (match_dup 3) (xor:SI (match_dup 1) (match_dup 4))) |
| 6992 | (set (match_dup 0) (compare:CC (match_dup 3) (match_dup 5)))] |
| 6993 | " |
| 6994 | @{ |
| 6995 | /* @r{Get the constant we are comparing against, C, and see what it |
| 6996 | looks like sign-extended to 16 bits. Then see what constant |
| 6997 | could be XOR'ed with C to get the sign-extended value.} */ |
| 6998 | |
| 6999 | int c = INTVAL (operands[2]); |
| 7000 | int sextc = (c << 16) >> 16; |
| 7001 | int xorv = c ^ sextc; |
| 7002 | |
| 7003 | operands[4] = GEN_INT (xorv); |
| 7004 | operands[5] = GEN_INT (sextc); |
| 7005 | @}") |
| 7006 | @end smallexample |
| 7007 | |
| 7008 | To avoid confusion, don't write a single @code{define_split} that |
| 7009 | accepts some insns that match some @code{define_insn} as well as some |
| 7010 | insns that don't. Instead, write two separate @code{define_split} |
| 7011 | definitions, one for the insns that are valid and one for the insns that |
| 7012 | are not valid. |
| 7013 | |
| 7014 | The splitter is allowed to split jump instructions into sequence of |
| 7015 | jumps or create new jumps in while splitting non-jump instructions. As |
| 7016 | the central flowgraph and branch prediction information needs to be updated, |
| 7017 | several restriction apply. |
| 7018 | |
| 7019 | Splitting of jump instruction into sequence that over by another jump |
| 7020 | instruction is always valid, as compiler expect identical behavior of new |
| 7021 | jump. When new sequence contains multiple jump instructions or new labels, |
| 7022 | more assistance is needed. Splitter is required to create only unconditional |
| 7023 | jumps, or simple conditional jump instructions. Additionally it must attach a |
| 7024 | @code{REG_BR_PROB} note to each conditional jump. A global variable |
| 7025 | @code{split_branch_probability} holds the probability of the original branch in case |
| 7026 | it was a simple conditional jump, @minus{}1 otherwise. To simplify |
| 7027 | recomputing of edge frequencies, the new sequence is required to have only |
| 7028 | forward jumps to the newly created labels. |
| 7029 | |
| 7030 | @findex define_insn_and_split |
| 7031 | For the common case where the pattern of a define_split exactly matches the |
| 7032 | pattern of a define_insn, use @code{define_insn_and_split}. It looks like |
| 7033 | this: |
| 7034 | |
| 7035 | @smallexample |
| 7036 | (define_insn_and_split |
| 7037 | [@var{insn-pattern}] |
| 7038 | "@var{condition}" |
| 7039 | "@var{output-template}" |
| 7040 | "@var{split-condition}" |
| 7041 | [@var{new-insn-pattern-1} |
| 7042 | @var{new-insn-pattern-2} |
| 7043 | @dots{}] |
| 7044 | "@var{preparation-statements}" |
| 7045 | [@var{insn-attributes}]) |
| 7046 | |
| 7047 | @end smallexample |
| 7048 | |
| 7049 | @var{insn-pattern}, @var{condition}, @var{output-template}, and |
| 7050 | @var{insn-attributes} are used as in @code{define_insn}. The |
| 7051 | @var{new-insn-pattern} vector and the @var{preparation-statements} are used as |
| 7052 | in a @code{define_split}. The @var{split-condition} is also used as in |
| 7053 | @code{define_split}, with the additional behavior that if the condition starts |
| 7054 | with @samp{&&}, the condition used for the split will be the constructed as a |
| 7055 | logical ``and'' of the split condition with the insn condition. For example, |
| 7056 | from i386.md: |
| 7057 | |
| 7058 | @smallexample |
| 7059 | (define_insn_and_split "zero_extendhisi2_and" |
| 7060 | [(set (match_operand:SI 0 "register_operand" "=r") |
| 7061 | (zero_extend:SI (match_operand:HI 1 "register_operand" "0"))) |
| 7062 | (clobber (reg:CC 17))] |
| 7063 | "TARGET_ZERO_EXTEND_WITH_AND && !optimize_size" |
| 7064 | "#" |
| 7065 | "&& reload_completed" |
| 7066 | [(parallel [(set (match_dup 0) |
| 7067 | (and:SI (match_dup 0) (const_int 65535))) |
| 7068 | (clobber (reg:CC 17))])] |
| 7069 | "" |
| 7070 | [(set_attr "type" "alu1")]) |
| 7071 | |
| 7072 | @end smallexample |
| 7073 | |
| 7074 | In this case, the actual split condition will be |
| 7075 | @samp{TARGET_ZERO_EXTEND_WITH_AND && !optimize_size && reload_completed}. |
| 7076 | |
| 7077 | The @code{define_insn_and_split} construction provides exactly the same |
| 7078 | functionality as two separate @code{define_insn} and @code{define_split} |
| 7079 | patterns. It exists for compactness, and as a maintenance tool to prevent |
| 7080 | having to ensure the two patterns' templates match. |
| 7081 | |
| 7082 | @end ifset |
| 7083 | @ifset INTERNALS |
| 7084 | @node Including Patterns |
| 7085 | @section Including Patterns in Machine Descriptions. |
| 7086 | @cindex insn includes |
| 7087 | |
| 7088 | @findex include |
| 7089 | The @code{include} pattern tells the compiler tools where to |
| 7090 | look for patterns that are in files other than in the file |
| 7091 | @file{.md}. This is used only at build time and there is no preprocessing allowed. |
| 7092 | |
| 7093 | It looks like: |
| 7094 | |
| 7095 | @smallexample |
| 7096 | |
| 7097 | (include |
| 7098 | @var{pathname}) |
| 7099 | @end smallexample |
| 7100 | |
| 7101 | For example: |
| 7102 | |
| 7103 | @smallexample |
| 7104 | |
| 7105 | (include "filestuff") |
| 7106 | |
| 7107 | @end smallexample |
| 7108 | |
| 7109 | Where @var{pathname} is a string that specifies the location of the file, |
| 7110 | specifies the include file to be in @file{gcc/config/target/filestuff}. The |
| 7111 | directory @file{gcc/config/target} is regarded as the default directory. |
| 7112 | |
| 7113 | |
| 7114 | Machine descriptions may be split up into smaller more manageable subsections |
| 7115 | and placed into subdirectories. |
| 7116 | |
| 7117 | By specifying: |
| 7118 | |
| 7119 | @smallexample |
| 7120 | |
| 7121 | (include "BOGUS/filestuff") |
| 7122 | |
| 7123 | @end smallexample |
| 7124 | |
| 7125 | the include file is specified to be in @file{gcc/config/@var{target}/BOGUS/filestuff}. |
| 7126 | |
| 7127 | Specifying an absolute path for the include file such as; |
| 7128 | @smallexample |
| 7129 | |
| 7130 | (include "/u2/BOGUS/filestuff") |
| 7131 | |
| 7132 | @end smallexample |
| 7133 | is permitted but is not encouraged. |
| 7134 | |
| 7135 | @subsection RTL Generation Tool Options for Directory Search |
| 7136 | @cindex directory options .md |
| 7137 | @cindex options, directory search |
| 7138 | @cindex search options |
| 7139 | |
| 7140 | The @option{-I@var{dir}} option specifies directories to search for machine descriptions. |
| 7141 | For example: |
| 7142 | |
| 7143 | @smallexample |
| 7144 | |
| 7145 | genrecog -I/p1/abc/proc1 -I/p2/abcd/pro2 target.md |
| 7146 | |
| 7147 | @end smallexample |
| 7148 | |
| 7149 | |
| 7150 | Add the directory @var{dir} to the head of the list of directories to be |
| 7151 | searched for header files. This can be used to override a system machine definition |
| 7152 | file, substituting your own version, since these directories are |
| 7153 | searched before the default machine description file directories. If you use more than |
| 7154 | one @option{-I} option, the directories are scanned in left-to-right |
| 7155 | order; the standard default directory come after. |
| 7156 | |
| 7157 | |
| 7158 | @end ifset |
| 7159 | @ifset INTERNALS |
| 7160 | @node Peephole Definitions |
| 7161 | @section Machine-Specific Peephole Optimizers |
| 7162 | @cindex peephole optimizer definitions |
| 7163 | @cindex defining peephole optimizers |
| 7164 | |
| 7165 | In addition to instruction patterns the @file{md} file may contain |
| 7166 | definitions of machine-specific peephole optimizations. |
| 7167 | |
| 7168 | The combiner does not notice certain peephole optimizations when the data |
| 7169 | flow in the program does not suggest that it should try them. For example, |
| 7170 | sometimes two consecutive insns related in purpose can be combined even |
| 7171 | though the second one does not appear to use a register computed in the |
| 7172 | first one. A machine-specific peephole optimizer can detect such |
| 7173 | opportunities. |
| 7174 | |
| 7175 | There are two forms of peephole definitions that may be used. The |
| 7176 | original @code{define_peephole} is run at assembly output time to |
| 7177 | match insns and substitute assembly text. Use of @code{define_peephole} |
| 7178 | is deprecated. |
| 7179 | |
| 7180 | A newer @code{define_peephole2} matches insns and substitutes new |
| 7181 | insns. The @code{peephole2} pass is run after register allocation |
| 7182 | but before scheduling, which may result in much better code for |
| 7183 | targets that do scheduling. |
| 7184 | |
| 7185 | @menu |
| 7186 | * define_peephole:: RTL to Text Peephole Optimizers |
| 7187 | * define_peephole2:: RTL to RTL Peephole Optimizers |
| 7188 | @end menu |
| 7189 | |
| 7190 | @end ifset |
| 7191 | @ifset INTERNALS |
| 7192 | @node define_peephole |
| 7193 | @subsection RTL to Text Peephole Optimizers |
| 7194 | @findex define_peephole |
| 7195 | |
| 7196 | @need 1000 |
| 7197 | A definition looks like this: |
| 7198 | |
| 7199 | @smallexample |
| 7200 | (define_peephole |
| 7201 | [@var{insn-pattern-1} |
| 7202 | @var{insn-pattern-2} |
| 7203 | @dots{}] |
| 7204 | "@var{condition}" |
| 7205 | "@var{template}" |
| 7206 | "@var{optional-insn-attributes}") |
| 7207 | @end smallexample |
| 7208 | |
| 7209 | @noindent |
| 7210 | The last string operand may be omitted if you are not using any |
| 7211 | machine-specific information in this machine description. If present, |
| 7212 | it must obey the same rules as in a @code{define_insn}. |
| 7213 | |
| 7214 | In this skeleton, @var{insn-pattern-1} and so on are patterns to match |
| 7215 | consecutive insns. The optimization applies to a sequence of insns when |
| 7216 | @var{insn-pattern-1} matches the first one, @var{insn-pattern-2} matches |
| 7217 | the next, and so on. |
| 7218 | |
| 7219 | Each of the insns matched by a peephole must also match a |
| 7220 | @code{define_insn}. Peepholes are checked only at the last stage just |
| 7221 | before code generation, and only optionally. Therefore, any insn which |
| 7222 | would match a peephole but no @code{define_insn} will cause a crash in code |
| 7223 | generation in an unoptimized compilation, or at various optimization |
| 7224 | stages. |
| 7225 | |
| 7226 | The operands of the insns are matched with @code{match_operands}, |
| 7227 | @code{match_operator}, and @code{match_dup}, as usual. What is not |
| 7228 | usual is that the operand numbers apply to all the insn patterns in the |
| 7229 | definition. So, you can check for identical operands in two insns by |
| 7230 | using @code{match_operand} in one insn and @code{match_dup} in the |
| 7231 | other. |
| 7232 | |
| 7233 | The operand constraints used in @code{match_operand} patterns do not have |
| 7234 | any direct effect on the applicability of the peephole, but they will |
| 7235 | be validated afterward, so make sure your constraints are general enough |
| 7236 | to apply whenever the peephole matches. If the peephole matches |
| 7237 | but the constraints are not satisfied, the compiler will crash. |
| 7238 | |
| 7239 | It is safe to omit constraints in all the operands of the peephole; or |
| 7240 | you can write constraints which serve as a double-check on the criteria |
| 7241 | previously tested. |
| 7242 | |
| 7243 | Once a sequence of insns matches the patterns, the @var{condition} is |
| 7244 | checked. This is a C expression which makes the final decision whether to |
| 7245 | perform the optimization (we do so if the expression is nonzero). If |
| 7246 | @var{condition} is omitted (in other words, the string is empty) then the |
| 7247 | optimization is applied to every sequence of insns that matches the |
| 7248 | patterns. |
| 7249 | |
| 7250 | The defined peephole optimizations are applied after register allocation |
| 7251 | is complete. Therefore, the peephole definition can check which |
| 7252 | operands have ended up in which kinds of registers, just by looking at |
| 7253 | the operands. |
| 7254 | |
| 7255 | @findex prev_active_insn |
| 7256 | The way to refer to the operands in @var{condition} is to write |
| 7257 | @code{operands[@var{i}]} for operand number @var{i} (as matched by |
| 7258 | @code{(match_operand @var{i} @dots{})}). Use the variable @code{insn} |
| 7259 | to refer to the last of the insns being matched; use |
| 7260 | @code{prev_active_insn} to find the preceding insns. |
| 7261 | |
| 7262 | @findex dead_or_set_p |
| 7263 | When optimizing computations with intermediate results, you can use |
| 7264 | @var{condition} to match only when the intermediate results are not used |
| 7265 | elsewhere. Use the C expression @code{dead_or_set_p (@var{insn}, |
| 7266 | @var{op})}, where @var{insn} is the insn in which you expect the value |
| 7267 | to be used for the last time (from the value of @code{insn}, together |
| 7268 | with use of @code{prev_nonnote_insn}), and @var{op} is the intermediate |
| 7269 | value (from @code{operands[@var{i}]}). |
| 7270 | |
| 7271 | Applying the optimization means replacing the sequence of insns with one |
| 7272 | new insn. The @var{template} controls ultimate output of assembler code |
| 7273 | for this combined insn. It works exactly like the template of a |
| 7274 | @code{define_insn}. Operand numbers in this template are the same ones |
| 7275 | used in matching the original sequence of insns. |
| 7276 | |
| 7277 | The result of a defined peephole optimizer does not need to match any of |
| 7278 | the insn patterns in the machine description; it does not even have an |
| 7279 | opportunity to match them. The peephole optimizer definition itself serves |
| 7280 | as the insn pattern to control how the insn is output. |
| 7281 | |
| 7282 | Defined peephole optimizers are run as assembler code is being output, |
| 7283 | so the insns they produce are never combined or rearranged in any way. |
| 7284 | |
| 7285 | Here is an example, taken from the 68000 machine description: |
| 7286 | |
| 7287 | @smallexample |
| 7288 | (define_peephole |
| 7289 | [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4))) |
| 7290 | (set (match_operand:DF 0 "register_operand" "=f") |
| 7291 | (match_operand:DF 1 "register_operand" "ad"))] |
| 7292 | "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])" |
| 7293 | @{ |
| 7294 | rtx xoperands[2]; |
| 7295 | xoperands[1] = gen_rtx_REG (SImode, REGNO (operands[1]) + 1); |
| 7296 | #ifdef MOTOROLA |
| 7297 | output_asm_insn ("move.l %1,(sp)", xoperands); |
| 7298 | output_asm_insn ("move.l %1,-(sp)", operands); |
| 7299 | return "fmove.d (sp)+,%0"; |
| 7300 | #else |
| 7301 | output_asm_insn ("movel %1,sp@@", xoperands); |
| 7302 | output_asm_insn ("movel %1,sp@@-", operands); |
| 7303 | return "fmoved sp@@+,%0"; |
| 7304 | #endif |
| 7305 | @}) |
| 7306 | @end smallexample |
| 7307 | |
| 7308 | @need 1000 |
| 7309 | The effect of this optimization is to change |
| 7310 | |
| 7311 | @smallexample |
| 7312 | @group |
| 7313 | jbsr _foobar |
| 7314 | addql #4,sp |
| 7315 | movel d1,sp@@- |
| 7316 | movel d0,sp@@- |
| 7317 | fmoved sp@@+,fp0 |
| 7318 | @end group |
| 7319 | @end smallexample |
| 7320 | |
| 7321 | @noindent |
| 7322 | into |
| 7323 | |
| 7324 | @smallexample |
| 7325 | @group |
| 7326 | jbsr _foobar |
| 7327 | movel d1,sp@@ |
| 7328 | movel d0,sp@@- |
| 7329 | fmoved sp@@+,fp0 |
| 7330 | @end group |
| 7331 | @end smallexample |
| 7332 | |
| 7333 | @ignore |
| 7334 | @findex CC_REVERSED |
| 7335 | If a peephole matches a sequence including one or more jump insns, you must |
| 7336 | take account of the flags such as @code{CC_REVERSED} which specify that the |
| 7337 | condition codes are represented in an unusual manner. The compiler |
| 7338 | automatically alters any ordinary conditional jumps which occur in such |
| 7339 | situations, but the compiler cannot alter jumps which have been replaced by |
| 7340 | peephole optimizations. So it is up to you to alter the assembler code |
| 7341 | that the peephole produces. Supply C code to write the assembler output, |
| 7342 | and in this C code check the condition code status flags and change the |
| 7343 | assembler code as appropriate. |
| 7344 | @end ignore |
| 7345 | |
| 7346 | @var{insn-pattern-1} and so on look @emph{almost} like the second |
| 7347 | operand of @code{define_insn}. There is one important difference: the |
| 7348 | second operand of @code{define_insn} consists of one or more RTX's |
| 7349 | enclosed in square brackets. Usually, there is only one: then the same |
| 7350 | action can be written as an element of a @code{define_peephole}. But |
| 7351 | when there are multiple actions in a @code{define_insn}, they are |
| 7352 | implicitly enclosed in a @code{parallel}. Then you must explicitly |
| 7353 | write the @code{parallel}, and the square brackets within it, in the |
| 7354 | @code{define_peephole}. Thus, if an insn pattern looks like this, |
| 7355 | |
| 7356 | @smallexample |
| 7357 | (define_insn "divmodsi4" |
| 7358 | [(set (match_operand:SI 0 "general_operand" "=d") |
| 7359 | (div:SI (match_operand:SI 1 "general_operand" "0") |
| 7360 | (match_operand:SI 2 "general_operand" "dmsK"))) |
| 7361 | (set (match_operand:SI 3 "general_operand" "=d") |
| 7362 | (mod:SI (match_dup 1) (match_dup 2)))] |
| 7363 | "TARGET_68020" |
| 7364 | "divsl%.l %2,%3:%0") |
| 7365 | @end smallexample |
| 7366 | |
| 7367 | @noindent |
| 7368 | then the way to mention this insn in a peephole is as follows: |
| 7369 | |
| 7370 | @smallexample |
| 7371 | (define_peephole |
| 7372 | [@dots{} |
| 7373 | (parallel |
| 7374 | [(set (match_operand:SI 0 "general_operand" "=d") |
| 7375 | (div:SI (match_operand:SI 1 "general_operand" "0") |
| 7376 | (match_operand:SI 2 "general_operand" "dmsK"))) |
| 7377 | (set (match_operand:SI 3 "general_operand" "=d") |
| 7378 | (mod:SI (match_dup 1) (match_dup 2)))]) |
| 7379 | @dots{}] |
| 7380 | @dots{}) |
| 7381 | @end smallexample |
| 7382 | |
| 7383 | @end ifset |
| 7384 | @ifset INTERNALS |
| 7385 | @node define_peephole2 |
| 7386 | @subsection RTL to RTL Peephole Optimizers |
| 7387 | @findex define_peephole2 |
| 7388 | |
| 7389 | The @code{define_peephole2} definition tells the compiler how to |
| 7390 | substitute one sequence of instructions for another sequence, |
| 7391 | what additional scratch registers may be needed and what their |
| 7392 | lifetimes must be. |
| 7393 | |
| 7394 | @smallexample |
| 7395 | (define_peephole2 |
| 7396 | [@var{insn-pattern-1} |
| 7397 | @var{insn-pattern-2} |
| 7398 | @dots{}] |
| 7399 | "@var{condition}" |
| 7400 | [@var{new-insn-pattern-1} |
| 7401 | @var{new-insn-pattern-2} |
| 7402 | @dots{}] |
| 7403 | "@var{preparation-statements}") |
| 7404 | @end smallexample |
| 7405 | |
| 7406 | The definition is almost identical to @code{define_split} |
| 7407 | (@pxref{Insn Splitting}) except that the pattern to match is not a |
| 7408 | single instruction, but a sequence of instructions. |
| 7409 | |
| 7410 | It is possible to request additional scratch registers for use in the |
| 7411 | output template. If appropriate registers are not free, the pattern |
| 7412 | will simply not match. |
| 7413 | |
| 7414 | @findex match_scratch |
| 7415 | @findex match_dup |
| 7416 | Scratch registers are requested with a @code{match_scratch} pattern at |
| 7417 | the top level of the input pattern. The allocated register (initially) will |
| 7418 | be dead at the point requested within the original sequence. If the scratch |
| 7419 | is used at more than a single point, a @code{match_dup} pattern at the |
| 7420 | top level of the input pattern marks the last position in the input sequence |
| 7421 | at which the register must be available. |
| 7422 | |
| 7423 | Here is an example from the IA-32 machine description: |
| 7424 | |
| 7425 | @smallexample |
| 7426 | (define_peephole2 |
| 7427 | [(match_scratch:SI 2 "r") |
| 7428 | (parallel [(set (match_operand:SI 0 "register_operand" "") |
| 7429 | (match_operator:SI 3 "arith_or_logical_operator" |
| 7430 | [(match_dup 0) |
| 7431 | (match_operand:SI 1 "memory_operand" "")])) |
| 7432 | (clobber (reg:CC 17))])] |
| 7433 | "! optimize_size && ! TARGET_READ_MODIFY" |
| 7434 | [(set (match_dup 2) (match_dup 1)) |
| 7435 | (parallel [(set (match_dup 0) |
| 7436 | (match_op_dup 3 [(match_dup 0) (match_dup 2)])) |
| 7437 | (clobber (reg:CC 17))])] |
| 7438 | "") |
| 7439 | @end smallexample |
| 7440 | |
| 7441 | @noindent |
| 7442 | This pattern tries to split a load from its use in the hopes that we'll be |
| 7443 | able to schedule around the memory load latency. It allocates a single |
| 7444 | @code{SImode} register of class @code{GENERAL_REGS} (@code{"r"}) that needs |
| 7445 | to be live only at the point just before the arithmetic. |
| 7446 | |
| 7447 | A real example requiring extended scratch lifetimes is harder to come by, |
| 7448 | so here's a silly made-up example: |
| 7449 | |
| 7450 | @smallexample |
| 7451 | (define_peephole2 |
| 7452 | [(match_scratch:SI 4 "r") |
| 7453 | (set (match_operand:SI 0 "" "") (match_operand:SI 1 "" "")) |
| 7454 | (set (match_operand:SI 2 "" "") (match_dup 1)) |
| 7455 | (match_dup 4) |
| 7456 | (set (match_operand:SI 3 "" "") (match_dup 1))] |
| 7457 | "/* @r{determine 1 does not overlap 0 and 2} */" |
| 7458 | [(set (match_dup 4) (match_dup 1)) |
| 7459 | (set (match_dup 0) (match_dup 4)) |
| 7460 | (set (match_dup 2) (match_dup 4))] |
| 7461 | (set (match_dup 3) (match_dup 4))] |
| 7462 | "") |
| 7463 | @end smallexample |
| 7464 | |
| 7465 | @noindent |
| 7466 | If we had not added the @code{(match_dup 4)} in the middle of the input |
| 7467 | sequence, it might have been the case that the register we chose at the |
| 7468 | beginning of the sequence is killed by the first or second @code{set}. |
| 7469 | |
| 7470 | @end ifset |
| 7471 | @ifset INTERNALS |
| 7472 | @node Insn Attributes |
| 7473 | @section Instruction Attributes |
| 7474 | @cindex insn attributes |
| 7475 | @cindex instruction attributes |
| 7476 | |
| 7477 | In addition to describing the instruction supported by the target machine, |
| 7478 | the @file{md} file also defines a group of @dfn{attributes} and a set of |
| 7479 | values for each. Every generated insn is assigned a value for each attribute. |
| 7480 | One possible attribute would be the effect that the insn has on the machine's |
| 7481 | condition code. This attribute can then be used by @code{NOTICE_UPDATE_CC} |
| 7482 | to track the condition codes. |
| 7483 | |
| 7484 | @menu |
| 7485 | * Defining Attributes:: Specifying attributes and their values. |
| 7486 | * Expressions:: Valid expressions for attribute values. |
| 7487 | * Tagging Insns:: Assigning attribute values to insns. |
| 7488 | * Attr Example:: An example of assigning attributes. |
| 7489 | * Insn Lengths:: Computing the length of insns. |
| 7490 | * Constant Attributes:: Defining attributes that are constant. |
| 7491 | * Delay Slots:: Defining delay slots required for a machine. |
| 7492 | * Processor pipeline description:: Specifying information for insn scheduling. |
| 7493 | @end menu |
| 7494 | |
| 7495 | @end ifset |
| 7496 | @ifset INTERNALS |
| 7497 | @node Defining Attributes |
| 7498 | @subsection Defining Attributes and their Values |
| 7499 | @cindex defining attributes and their values |
| 7500 | @cindex attributes, defining |
| 7501 | |
| 7502 | @findex define_attr |
| 7503 | The @code{define_attr} expression is used to define each attribute required |
| 7504 | by the target machine. It looks like: |
| 7505 | |
| 7506 | @smallexample |
| 7507 | (define_attr @var{name} @var{list-of-values} @var{default}) |
| 7508 | @end smallexample |
| 7509 | |
| 7510 | @var{name} is a string specifying the name of the attribute being defined. |
| 7511 | Some attributes are used in a special way by the rest of the compiler. The |
| 7512 | @code{enabled} attribute can be used to conditionally enable or disable |
| 7513 | insn alternatives (@pxref{Disable Insn Alternatives}). The @code{predicable} |
| 7514 | attribute, together with a suitable @code{define_cond_exec} |
| 7515 | (@pxref{Conditional Execution}), can be used to automatically generate |
| 7516 | conditional variants of instruction patterns. The compiler internally uses |
| 7517 | the names @code{ce_enabled} and @code{nonce_enabled}, so they should not be |
| 7518 | used elsewhere as alternative names. |
| 7519 | |
| 7520 | @var{list-of-values} is either a string that specifies a comma-separated |
| 7521 | list of values that can be assigned to the attribute, or a null string to |
| 7522 | indicate that the attribute takes numeric values. |
| 7523 | |
| 7524 | @var{default} is an attribute expression that gives the value of this |
| 7525 | attribute for insns that match patterns whose definition does not include |
| 7526 | an explicit value for this attribute. @xref{Attr Example}, for more |
| 7527 | information on the handling of defaults. @xref{Constant Attributes}, |
| 7528 | for information on attributes that do not depend on any particular insn. |
| 7529 | |
| 7530 | @findex insn-attr.h |
| 7531 | For each defined attribute, a number of definitions are written to the |
| 7532 | @file{insn-attr.h} file. For cases where an explicit set of values is |
| 7533 | specified for an attribute, the following are defined: |
| 7534 | |
| 7535 | @itemize @bullet |
| 7536 | @item |
| 7537 | A @samp{#define} is written for the symbol @samp{HAVE_ATTR_@var{name}}. |
| 7538 | |
| 7539 | @item |
| 7540 | An enumerated class is defined for @samp{attr_@var{name}} with |
| 7541 | elements of the form @samp{@var{upper-name}_@var{upper-value}} where |
| 7542 | the attribute name and value are first converted to uppercase. |
| 7543 | |
| 7544 | @item |
| 7545 | A function @samp{get_attr_@var{name}} is defined that is passed an insn and |
| 7546 | returns the attribute value for that insn. |
| 7547 | @end itemize |
| 7548 | |
| 7549 | For example, if the following is present in the @file{md} file: |
| 7550 | |
| 7551 | @smallexample |
| 7552 | (define_attr "type" "branch,fp,load,store,arith" @dots{}) |
| 7553 | @end smallexample |
| 7554 | |
| 7555 | @noindent |
| 7556 | the following lines will be written to the file @file{insn-attr.h}. |
| 7557 | |
| 7558 | @smallexample |
| 7559 | #define HAVE_ATTR_type |
| 7560 | enum attr_type @{TYPE_BRANCH, TYPE_FP, TYPE_LOAD, |
| 7561 | TYPE_STORE, TYPE_ARITH@}; |
| 7562 | extern enum attr_type get_attr_type (); |
| 7563 | @end smallexample |
| 7564 | |
| 7565 | If the attribute takes numeric values, no @code{enum} type will be |
| 7566 | defined and the function to obtain the attribute's value will return |
| 7567 | @code{int}. |
| 7568 | |
| 7569 | There are attributes which are tied to a specific meaning. These |
| 7570 | attributes are not free to use for other purposes: |
| 7571 | |
| 7572 | @table @code |
| 7573 | @item length |
| 7574 | The @code{length} attribute is used to calculate the length of emitted |
| 7575 | code chunks. This is especially important when verifying branch |
| 7576 | distances. @xref{Insn Lengths}. |
| 7577 | |
| 7578 | @item enabled |
| 7579 | The @code{enabled} attribute can be defined to prevent certain |
| 7580 | alternatives of an insn definition from being used during code |
| 7581 | generation. @xref{Disable Insn Alternatives}. |
| 7582 | @end table |
| 7583 | |
| 7584 | @findex define_enum_attr |
| 7585 | @anchor{define_enum_attr} |
| 7586 | Another way of defining an attribute is to use: |
| 7587 | |
| 7588 | @smallexample |
| 7589 | (define_enum_attr "@var{attr}" "@var{enum}" @var{default}) |
| 7590 | @end smallexample |
| 7591 | |
| 7592 | This works in just the same way as @code{define_attr}, except that |
| 7593 | the list of values is taken from a separate enumeration called |
| 7594 | @var{enum} (@pxref{define_enum}). This form allows you to use |
| 7595 | the same list of values for several attributes without having to |
| 7596 | repeat the list each time. For example: |
| 7597 | |
| 7598 | @smallexample |
| 7599 | (define_enum "processor" [ |
| 7600 | model_a |
| 7601 | model_b |
| 7602 | @dots{} |
| 7603 | ]) |
| 7604 | (define_enum_attr "arch" "processor" |
| 7605 | (const (symbol_ref "target_arch"))) |
| 7606 | (define_enum_attr "tune" "processor" |
| 7607 | (const (symbol_ref "target_tune"))) |
| 7608 | @end smallexample |
| 7609 | |
| 7610 | defines the same attributes as: |
| 7611 | |
| 7612 | @smallexample |
| 7613 | (define_attr "arch" "model_a,model_b,@dots{}" |
| 7614 | (const (symbol_ref "target_arch"))) |
| 7615 | (define_attr "tune" "model_a,model_b,@dots{}" |
| 7616 | (const (symbol_ref "target_tune"))) |
| 7617 | @end smallexample |
| 7618 | |
| 7619 | but without duplicating the processor list. The second example defines two |
| 7620 | separate C enums (@code{attr_arch} and @code{attr_tune}) whereas the first |
| 7621 | defines a single C enum (@code{processor}). |
| 7622 | @end ifset |
| 7623 | @ifset INTERNALS |
| 7624 | @node Expressions |
| 7625 | @subsection Attribute Expressions |
| 7626 | @cindex attribute expressions |
| 7627 | |
| 7628 | RTL expressions used to define attributes use the codes described above |
| 7629 | plus a few specific to attribute definitions, to be discussed below. |
| 7630 | Attribute value expressions must have one of the following forms: |
| 7631 | |
| 7632 | @table @code |
| 7633 | @cindex @code{const_int} and attributes |
| 7634 | @item (const_int @var{i}) |
| 7635 | The integer @var{i} specifies the value of a numeric attribute. @var{i} |
| 7636 | must be non-negative. |
| 7637 | |
| 7638 | The value of a numeric attribute can be specified either with a |
| 7639 | @code{const_int}, or as an integer represented as a string in |
| 7640 | @code{const_string}, @code{eq_attr} (see below), @code{attr}, |
| 7641 | @code{symbol_ref}, simple arithmetic expressions, and @code{set_attr} |
| 7642 | overrides on specific instructions (@pxref{Tagging Insns}). |
| 7643 | |
| 7644 | @cindex @code{const_string} and attributes |
| 7645 | @item (const_string @var{value}) |
| 7646 | The string @var{value} specifies a constant attribute value. |
| 7647 | If @var{value} is specified as @samp{"*"}, it means that the default value of |
| 7648 | the attribute is to be used for the insn containing this expression. |
| 7649 | @samp{"*"} obviously cannot be used in the @var{default} expression |
| 7650 | of a @code{define_attr}. |
| 7651 | |
| 7652 | If the attribute whose value is being specified is numeric, @var{value} |
| 7653 | must be a string containing a non-negative integer (normally |
| 7654 | @code{const_int} would be used in this case). Otherwise, it must |
| 7655 | contain one of the valid values for the attribute. |
| 7656 | |
| 7657 | @cindex @code{if_then_else} and attributes |
| 7658 | @item (if_then_else @var{test} @var{true-value} @var{false-value}) |
| 7659 | @var{test} specifies an attribute test, whose format is defined below. |
| 7660 | The value of this expression is @var{true-value} if @var{test} is true, |
| 7661 | otherwise it is @var{false-value}. |
| 7662 | |
| 7663 | @cindex @code{cond} and attributes |
| 7664 | @item (cond [@var{test1} @var{value1} @dots{}] @var{default}) |
| 7665 | The first operand of this expression is a vector containing an even |
| 7666 | number of expressions and consisting of pairs of @var{test} and @var{value} |
| 7667 | expressions. The value of the @code{cond} expression is that of the |
| 7668 | @var{value} corresponding to the first true @var{test} expression. If |
| 7669 | none of the @var{test} expressions are true, the value of the @code{cond} |
| 7670 | expression is that of the @var{default} expression. |
| 7671 | @end table |
| 7672 | |
| 7673 | @var{test} expressions can have one of the following forms: |
| 7674 | |
| 7675 | @table @code |
| 7676 | @cindex @code{const_int} and attribute tests |
| 7677 | @item (const_int @var{i}) |
| 7678 | This test is true if @var{i} is nonzero and false otherwise. |
| 7679 | |
| 7680 | @cindex @code{not} and attributes |
| 7681 | @cindex @code{ior} and attributes |
| 7682 | @cindex @code{and} and attributes |
| 7683 | @item (not @var{test}) |
| 7684 | @itemx (ior @var{test1} @var{test2}) |
| 7685 | @itemx (and @var{test1} @var{test2}) |
| 7686 | These tests are true if the indicated logical function is true. |
| 7687 | |
| 7688 | @cindex @code{match_operand} and attributes |
| 7689 | @item (match_operand:@var{m} @var{n} @var{pred} @var{constraints}) |
| 7690 | This test is true if operand @var{n} of the insn whose attribute value |
| 7691 | is being determined has mode @var{m} (this part of the test is ignored |
| 7692 | if @var{m} is @code{VOIDmode}) and the function specified by the string |
| 7693 | @var{pred} returns a nonzero value when passed operand @var{n} and mode |
| 7694 | @var{m} (this part of the test is ignored if @var{pred} is the null |
| 7695 | string). |
| 7696 | |
| 7697 | The @var{constraints} operand is ignored and should be the null string. |
| 7698 | |
| 7699 | @cindex @code{match_test} and attributes |
| 7700 | @item (match_test @var{c-expr}) |
| 7701 | The test is true if C expression @var{c-expr} is true. In non-constant |
| 7702 | attributes, @var{c-expr} has access to the following variables: |
| 7703 | |
| 7704 | @table @var |
| 7705 | @item insn |
| 7706 | The rtl instruction under test. |
| 7707 | @item which_alternative |
| 7708 | The @code{define_insn} alternative that @var{insn} matches. |
| 7709 | @xref{Output Statement}. |
| 7710 | @item operands |
| 7711 | An array of @var{insn}'s rtl operands. |
| 7712 | @end table |
| 7713 | |
| 7714 | @var{c-expr} behaves like the condition in a C @code{if} statement, |
| 7715 | so there is no need to explicitly convert the expression into a boolean |
| 7716 | 0 or 1 value. For example, the following two tests are equivalent: |
| 7717 | |
| 7718 | @smallexample |
| 7719 | (match_test "x & 2") |
| 7720 | (match_test "(x & 2) != 0") |
| 7721 | @end smallexample |
| 7722 | |
| 7723 | @cindex @code{le} and attributes |
| 7724 | @cindex @code{leu} and attributes |
| 7725 | @cindex @code{lt} and attributes |
| 7726 | @cindex @code{gt} and attributes |
| 7727 | @cindex @code{gtu} and attributes |
| 7728 | @cindex @code{ge} and attributes |
| 7729 | @cindex @code{geu} and attributes |
| 7730 | @cindex @code{ne} and attributes |
| 7731 | @cindex @code{eq} and attributes |
| 7732 | @cindex @code{plus} and attributes |
| 7733 | @cindex @code{minus} and attributes |
| 7734 | @cindex @code{mult} and attributes |
| 7735 | @cindex @code{div} and attributes |
| 7736 | @cindex @code{mod} and attributes |
| 7737 | @cindex @code{abs} and attributes |
| 7738 | @cindex @code{neg} and attributes |
| 7739 | @cindex @code{ashift} and attributes |
| 7740 | @cindex @code{lshiftrt} and attributes |
| 7741 | @cindex @code{ashiftrt} and attributes |
| 7742 | @item (le @var{arith1} @var{arith2}) |
| 7743 | @itemx (leu @var{arith1} @var{arith2}) |
| 7744 | @itemx (lt @var{arith1} @var{arith2}) |
| 7745 | @itemx (ltu @var{arith1} @var{arith2}) |
| 7746 | @itemx (gt @var{arith1} @var{arith2}) |
| 7747 | @itemx (gtu @var{arith1} @var{arith2}) |
| 7748 | @itemx (ge @var{arith1} @var{arith2}) |
| 7749 | @itemx (geu @var{arith1} @var{arith2}) |
| 7750 | @itemx (ne @var{arith1} @var{arith2}) |
| 7751 | @itemx (eq @var{arith1} @var{arith2}) |
| 7752 | These tests are true if the indicated comparison of the two arithmetic |
| 7753 | expressions is true. Arithmetic expressions are formed with |
| 7754 | @code{plus}, @code{minus}, @code{mult}, @code{div}, @code{mod}, |
| 7755 | @code{abs}, @code{neg}, @code{and}, @code{ior}, @code{xor}, @code{not}, |
| 7756 | @code{ashift}, @code{lshiftrt}, and @code{ashiftrt} expressions. |
| 7757 | |
| 7758 | @findex get_attr |
| 7759 | @code{const_int} and @code{symbol_ref} are always valid terms (@pxref{Insn |
| 7760 | Lengths},for additional forms). @code{symbol_ref} is a string |
| 7761 | denoting a C expression that yields an @code{int} when evaluated by the |
| 7762 | @samp{get_attr_@dots{}} routine. It should normally be a global |
| 7763 | variable. |
| 7764 | |
| 7765 | @findex eq_attr |
| 7766 | @item (eq_attr @var{name} @var{value}) |
| 7767 | @var{name} is a string specifying the name of an attribute. |
| 7768 | |
| 7769 | @var{value} is a string that is either a valid value for attribute |
| 7770 | @var{name}, a comma-separated list of values, or @samp{!} followed by a |
| 7771 | value or list. If @var{value} does not begin with a @samp{!}, this |
| 7772 | test is true if the value of the @var{name} attribute of the current |
| 7773 | insn is in the list specified by @var{value}. If @var{value} begins |
| 7774 | with a @samp{!}, this test is true if the attribute's value is |
| 7775 | @emph{not} in the specified list. |
| 7776 | |
| 7777 | For example, |
| 7778 | |
| 7779 | @smallexample |
| 7780 | (eq_attr "type" "load,store") |
| 7781 | @end smallexample |
| 7782 | |
| 7783 | @noindent |
| 7784 | is equivalent to |
| 7785 | |
| 7786 | @smallexample |
| 7787 | (ior (eq_attr "type" "load") (eq_attr "type" "store")) |
| 7788 | @end smallexample |
| 7789 | |
| 7790 | If @var{name} specifies an attribute of @samp{alternative}, it refers to the |
| 7791 | value of the compiler variable @code{which_alternative} |
| 7792 | (@pxref{Output Statement}) and the values must be small integers. For |
| 7793 | example, |
| 7794 | |
| 7795 | @smallexample |
| 7796 | (eq_attr "alternative" "2,3") |
| 7797 | @end smallexample |
| 7798 | |
| 7799 | @noindent |
| 7800 | is equivalent to |
| 7801 | |
| 7802 | @smallexample |
| 7803 | (ior (eq (symbol_ref "which_alternative") (const_int 2)) |
| 7804 | (eq (symbol_ref "which_alternative") (const_int 3))) |
| 7805 | @end smallexample |
| 7806 | |
| 7807 | Note that, for most attributes, an @code{eq_attr} test is simplified in cases |
| 7808 | where the value of the attribute being tested is known for all insns matching |
| 7809 | a particular pattern. This is by far the most common case. |
| 7810 | |
| 7811 | @findex attr_flag |
| 7812 | @item (attr_flag @var{name}) |
| 7813 | The value of an @code{attr_flag} expression is true if the flag |
| 7814 | specified by @var{name} is true for the @code{insn} currently being |
| 7815 | scheduled. |
| 7816 | |
| 7817 | @var{name} is a string specifying one of a fixed set of flags to test. |
| 7818 | Test the flags @code{forward} and @code{backward} to determine the |
| 7819 | direction of a conditional branch. |
| 7820 | |
| 7821 | This example describes a conditional branch delay slot which |
| 7822 | can be nullified for forward branches that are taken (annul-true) or |
| 7823 | for backward branches which are not taken (annul-false). |
| 7824 | |
| 7825 | @smallexample |
| 7826 | (define_delay (eq_attr "type" "cbranch") |
| 7827 | [(eq_attr "in_branch_delay" "true") |
| 7828 | (and (eq_attr "in_branch_delay" "true") |
| 7829 | (attr_flag "forward")) |
| 7830 | (and (eq_attr "in_branch_delay" "true") |
| 7831 | (attr_flag "backward"))]) |
| 7832 | @end smallexample |
| 7833 | |
| 7834 | The @code{forward} and @code{backward} flags are false if the current |
| 7835 | @code{insn} being scheduled is not a conditional branch. |
| 7836 | |
| 7837 | @code{attr_flag} is only used during delay slot scheduling and has no |
| 7838 | meaning to other passes of the compiler. |
| 7839 | |
| 7840 | @findex attr |
| 7841 | @item (attr @var{name}) |
| 7842 | The value of another attribute is returned. This is most useful |
| 7843 | for numeric attributes, as @code{eq_attr} and @code{attr_flag} |
| 7844 | produce more efficient code for non-numeric attributes. |
| 7845 | @end table |
| 7846 | |
| 7847 | @end ifset |
| 7848 | @ifset INTERNALS |
| 7849 | @node Tagging Insns |
| 7850 | @subsection Assigning Attribute Values to Insns |
| 7851 | @cindex tagging insns |
| 7852 | @cindex assigning attribute values to insns |
| 7853 | |
| 7854 | The value assigned to an attribute of an insn is primarily determined by |
| 7855 | which pattern is matched by that insn (or which @code{define_peephole} |
| 7856 | generated it). Every @code{define_insn} and @code{define_peephole} can |
| 7857 | have an optional last argument to specify the values of attributes for |
| 7858 | matching insns. The value of any attribute not specified in a particular |
| 7859 | insn is set to the default value for that attribute, as specified in its |
| 7860 | @code{define_attr}. Extensive use of default values for attributes |
| 7861 | permits the specification of the values for only one or two attributes |
| 7862 | in the definition of most insn patterns, as seen in the example in the |
| 7863 | next section. |
| 7864 | |
| 7865 | The optional last argument of @code{define_insn} and |
| 7866 | @code{define_peephole} is a vector of expressions, each of which defines |
| 7867 | the value for a single attribute. The most general way of assigning an |
| 7868 | attribute's value is to use a @code{set} expression whose first operand is an |
| 7869 | @code{attr} expression giving the name of the attribute being set. The |
| 7870 | second operand of the @code{set} is an attribute expression |
| 7871 | (@pxref{Expressions}) giving the value of the attribute. |
| 7872 | |
| 7873 | When the attribute value depends on the @samp{alternative} attribute |
| 7874 | (i.e., which is the applicable alternative in the constraint of the |
| 7875 | insn), the @code{set_attr_alternative} expression can be used. It |
| 7876 | allows the specification of a vector of attribute expressions, one for |
| 7877 | each alternative. |
| 7878 | |
| 7879 | @findex set_attr |
| 7880 | When the generality of arbitrary attribute expressions is not required, |
| 7881 | the simpler @code{set_attr} expression can be used, which allows |
| 7882 | specifying a string giving either a single attribute value or a list |
| 7883 | of attribute values, one for each alternative. |
| 7884 | |
| 7885 | The form of each of the above specifications is shown below. In each case, |
| 7886 | @var{name} is a string specifying the attribute to be set. |
| 7887 | |
| 7888 | @table @code |
| 7889 | @item (set_attr @var{name} @var{value-string}) |
| 7890 | @var{value-string} is either a string giving the desired attribute value, |
| 7891 | or a string containing a comma-separated list giving the values for |
| 7892 | succeeding alternatives. The number of elements must match the number |
| 7893 | of alternatives in the constraint of the insn pattern. |
| 7894 | |
| 7895 | Note that it may be useful to specify @samp{*} for some alternative, in |
| 7896 | which case the attribute will assume its default value for insns matching |
| 7897 | that alternative. |
| 7898 | |
| 7899 | @findex set_attr_alternative |
| 7900 | @item (set_attr_alternative @var{name} [@var{value1} @var{value2} @dots{}]) |
| 7901 | Depending on the alternative of the insn, the value will be one of the |
| 7902 | specified values. This is a shorthand for using a @code{cond} with |
| 7903 | tests on the @samp{alternative} attribute. |
| 7904 | |
| 7905 | @findex attr |
| 7906 | @item (set (attr @var{name}) @var{value}) |
| 7907 | The first operand of this @code{set} must be the special RTL expression |
| 7908 | @code{attr}, whose sole operand is a string giving the name of the |
| 7909 | attribute being set. @var{value} is the value of the attribute. |
| 7910 | @end table |
| 7911 | |
| 7912 | The following shows three different ways of representing the same |
| 7913 | attribute value specification: |
| 7914 | |
| 7915 | @smallexample |
| 7916 | (set_attr "type" "load,store,arith") |
| 7917 | |
| 7918 | (set_attr_alternative "type" |
| 7919 | [(const_string "load") (const_string "store") |
| 7920 | (const_string "arith")]) |
| 7921 | |
| 7922 | (set (attr "type") |
| 7923 | (cond [(eq_attr "alternative" "1") (const_string "load") |
| 7924 | (eq_attr "alternative" "2") (const_string "store")] |
| 7925 | (const_string "arith"))) |
| 7926 | @end smallexample |
| 7927 | |
| 7928 | @need 1000 |
| 7929 | @findex define_asm_attributes |
| 7930 | The @code{define_asm_attributes} expression provides a mechanism to |
| 7931 | specify the attributes assigned to insns produced from an @code{asm} |
| 7932 | statement. It has the form: |
| 7933 | |
| 7934 | @smallexample |
| 7935 | (define_asm_attributes [@var{attr-sets}]) |
| 7936 | @end smallexample |
| 7937 | |
| 7938 | @noindent |
| 7939 | where @var{attr-sets} is specified the same as for both the |
| 7940 | @code{define_insn} and the @code{define_peephole} expressions. |
| 7941 | |
| 7942 | These values will typically be the ``worst case'' attribute values. For |
| 7943 | example, they might indicate that the condition code will be clobbered. |
| 7944 | |
| 7945 | A specification for a @code{length} attribute is handled specially. The |
| 7946 | way to compute the length of an @code{asm} insn is to multiply the |
| 7947 | length specified in the expression @code{define_asm_attributes} by the |
| 7948 | number of machine instructions specified in the @code{asm} statement, |
| 7949 | determined by counting the number of semicolons and newlines in the |
| 7950 | string. Therefore, the value of the @code{length} attribute specified |
| 7951 | in a @code{define_asm_attributes} should be the maximum possible length |
| 7952 | of a single machine instruction. |
| 7953 | |
| 7954 | @end ifset |
| 7955 | @ifset INTERNALS |
| 7956 | @node Attr Example |
| 7957 | @subsection Example of Attribute Specifications |
| 7958 | @cindex attribute specifications example |
| 7959 | @cindex attribute specifications |
| 7960 | |
| 7961 | The judicious use of defaulting is important in the efficient use of |
| 7962 | insn attributes. Typically, insns are divided into @dfn{types} and an |
| 7963 | attribute, customarily called @code{type}, is used to represent this |
| 7964 | value. This attribute is normally used only to define the default value |
| 7965 | for other attributes. An example will clarify this usage. |
| 7966 | |
| 7967 | Assume we have a RISC machine with a condition code and in which only |
| 7968 | full-word operations are performed in registers. Let us assume that we |
| 7969 | can divide all insns into loads, stores, (integer) arithmetic |
| 7970 | operations, floating point operations, and branches. |
| 7971 | |
| 7972 | Here we will concern ourselves with determining the effect of an insn on |
| 7973 | the condition code and will limit ourselves to the following possible |
| 7974 | effects: The condition code can be set unpredictably (clobbered), not |
| 7975 | be changed, be set to agree with the results of the operation, or only |
| 7976 | changed if the item previously set into the condition code has been |
| 7977 | modified. |
| 7978 | |
| 7979 | Here is part of a sample @file{md} file for such a machine: |
| 7980 | |
| 7981 | @smallexample |
| 7982 | (define_attr "type" "load,store,arith,fp,branch" (const_string "arith")) |
| 7983 | |
| 7984 | (define_attr "cc" "clobber,unchanged,set,change0" |
| 7985 | (cond [(eq_attr "type" "load") |
| 7986 | (const_string "change0") |
| 7987 | (eq_attr "type" "store,branch") |
| 7988 | (const_string "unchanged") |
| 7989 | (eq_attr "type" "arith") |
| 7990 | (if_then_else (match_operand:SI 0 "" "") |
| 7991 | (const_string "set") |
| 7992 | (const_string "clobber"))] |
| 7993 | (const_string "clobber"))) |
| 7994 | |
| 7995 | (define_insn "" |
| 7996 | [(set (match_operand:SI 0 "general_operand" "=r,r,m") |
| 7997 | (match_operand:SI 1 "general_operand" "r,m,r"))] |
| 7998 | "" |
| 7999 | "@@ |
| 8000 | move %0,%1 |
| 8001 | load %0,%1 |
| 8002 | store %0,%1" |
| 8003 | [(set_attr "type" "arith,load,store")]) |
| 8004 | @end smallexample |
| 8005 | |
| 8006 | Note that we assume in the above example that arithmetic operations |
| 8007 | performed on quantities smaller than a machine word clobber the condition |
| 8008 | code since they will set the condition code to a value corresponding to the |
| 8009 | full-word result. |
| 8010 | |
| 8011 | @end ifset |
| 8012 | @ifset INTERNALS |
| 8013 | @node Insn Lengths |
| 8014 | @subsection Computing the Length of an Insn |
| 8015 | @cindex insn lengths, computing |
| 8016 | @cindex computing the length of an insn |
| 8017 | |
| 8018 | For many machines, multiple types of branch instructions are provided, each |
| 8019 | for different length branch displacements. In most cases, the assembler |
| 8020 | will choose the correct instruction to use. However, when the assembler |
| 8021 | cannot do so, GCC can when a special attribute, the @code{length} |
| 8022 | attribute, is defined. This attribute must be defined to have numeric |
| 8023 | values by specifying a null string in its @code{define_attr}. |
| 8024 | |
| 8025 | In the case of the @code{length} attribute, two additional forms of |
| 8026 | arithmetic terms are allowed in test expressions: |
| 8027 | |
| 8028 | @table @code |
| 8029 | @cindex @code{match_dup} and attributes |
| 8030 | @item (match_dup @var{n}) |
| 8031 | This refers to the address of operand @var{n} of the current insn, which |
| 8032 | must be a @code{label_ref}. |
| 8033 | |
| 8034 | @cindex @code{pc} and attributes |
| 8035 | @item (pc) |
| 8036 | This refers to the address of the @emph{current} insn. It might have |
| 8037 | been more consistent with other usage to make this the address of the |
| 8038 | @emph{next} insn but this would be confusing because the length of the |
| 8039 | current insn is to be computed. |
| 8040 | @end table |
| 8041 | |
| 8042 | @cindex @code{addr_vec}, length of |
| 8043 | @cindex @code{addr_diff_vec}, length of |
| 8044 | For normal insns, the length will be determined by value of the |
| 8045 | @code{length} attribute. In the case of @code{addr_vec} and |
| 8046 | @code{addr_diff_vec} insn patterns, the length is computed as |
| 8047 | the number of vectors multiplied by the size of each vector. |
| 8048 | |
| 8049 | Lengths are measured in addressable storage units (bytes). |
| 8050 | |
| 8051 | The following macros can be used to refine the length computation: |
| 8052 | |
| 8053 | @table @code |
| 8054 | @findex ADJUST_INSN_LENGTH |
| 8055 | @item ADJUST_INSN_LENGTH (@var{insn}, @var{length}) |
| 8056 | If defined, modifies the length assigned to instruction @var{insn} as a |
| 8057 | function of the context in which it is used. @var{length} is an lvalue |
| 8058 | that contains the initially computed length of the insn and should be |
| 8059 | updated with the correct length of the insn. |
| 8060 | |
| 8061 | This macro will normally not be required. A case in which it is |
| 8062 | required is the ROMP@. On this machine, the size of an @code{addr_vec} |
| 8063 | insn must be increased by two to compensate for the fact that alignment |
| 8064 | may be required. |
| 8065 | @end table |
| 8066 | |
| 8067 | @findex get_attr_length |
| 8068 | The routine that returns @code{get_attr_length} (the value of the |
| 8069 | @code{length} attribute) can be used by the output routine to |
| 8070 | determine the form of the branch instruction to be written, as the |
| 8071 | example below illustrates. |
| 8072 | |
| 8073 | As an example of the specification of variable-length branches, consider |
| 8074 | the IBM 360. If we adopt the convention that a register will be set to |
| 8075 | the starting address of a function, we can jump to labels within 4k of |
| 8076 | the start using a four-byte instruction. Otherwise, we need a six-byte |
| 8077 | sequence to load the address from memory and then branch to it. |
| 8078 | |
| 8079 | On such a machine, a pattern for a branch instruction might be specified |
| 8080 | as follows: |
| 8081 | |
| 8082 | @smallexample |
| 8083 | (define_insn "jump" |
| 8084 | [(set (pc) |
| 8085 | (label_ref (match_operand 0 "" "")))] |
| 8086 | "" |
| 8087 | @{ |
| 8088 | return (get_attr_length (insn) == 4 |
| 8089 | ? "b %l0" : "l r15,=a(%l0); br r15"); |
| 8090 | @} |
| 8091 | [(set (attr "length") |
| 8092 | (if_then_else (lt (match_dup 0) (const_int 4096)) |
| 8093 | (const_int 4) |
| 8094 | (const_int 6)))]) |
| 8095 | @end smallexample |
| 8096 | |
| 8097 | @end ifset |
| 8098 | @ifset INTERNALS |
| 8099 | @node Constant Attributes |
| 8100 | @subsection Constant Attributes |
| 8101 | @cindex constant attributes |
| 8102 | |
| 8103 | A special form of @code{define_attr}, where the expression for the |
| 8104 | default value is a @code{const} expression, indicates an attribute that |
| 8105 | is constant for a given run of the compiler. Constant attributes may be |
| 8106 | used to specify which variety of processor is used. For example, |
| 8107 | |
| 8108 | @smallexample |
| 8109 | (define_attr "cpu" "m88100,m88110,m88000" |
| 8110 | (const |
| 8111 | (cond [(symbol_ref "TARGET_88100") (const_string "m88100") |
| 8112 | (symbol_ref "TARGET_88110") (const_string "m88110")] |
| 8113 | (const_string "m88000")))) |
| 8114 | |
| 8115 | (define_attr "memory" "fast,slow" |
| 8116 | (const |
| 8117 | (if_then_else (symbol_ref "TARGET_FAST_MEM") |
| 8118 | (const_string "fast") |
| 8119 | (const_string "slow")))) |
| 8120 | @end smallexample |
| 8121 | |
| 8122 | The routine generated for constant attributes has no parameters as it |
| 8123 | does not depend on any particular insn. RTL expressions used to define |
| 8124 | the value of a constant attribute may use the @code{symbol_ref} form, |
| 8125 | but may not use either the @code{match_operand} form or @code{eq_attr} |
| 8126 | forms involving insn attributes. |
| 8127 | |
| 8128 | @end ifset |
| 8129 | @ifset INTERNALS |
| 8130 | @node Delay Slots |
| 8131 | @subsection Delay Slot Scheduling |
| 8132 | @cindex delay slots, defining |
| 8133 | |
| 8134 | The insn attribute mechanism can be used to specify the requirements for |
| 8135 | delay slots, if any, on a target machine. An instruction is said to |
| 8136 | require a @dfn{delay slot} if some instructions that are physically |
| 8137 | after the instruction are executed as if they were located before it. |
| 8138 | Classic examples are branch and call instructions, which often execute |
| 8139 | the following instruction before the branch or call is performed. |
| 8140 | |
| 8141 | On some machines, conditional branch instructions can optionally |
| 8142 | @dfn{annul} instructions in the delay slot. This means that the |
| 8143 | instruction will not be executed for certain branch outcomes. Both |
| 8144 | instructions that annul if the branch is true and instructions that |
| 8145 | annul if the branch is false are supported. |
| 8146 | |
| 8147 | Delay slot scheduling differs from instruction scheduling in that |
| 8148 | determining whether an instruction needs a delay slot is dependent only |
| 8149 | on the type of instruction being generated, not on data flow between the |
| 8150 | instructions. See the next section for a discussion of data-dependent |
| 8151 | instruction scheduling. |
| 8152 | |
| 8153 | @findex define_delay |
| 8154 | The requirement of an insn needing one or more delay slots is indicated |
| 8155 | via the @code{define_delay} expression. It has the following form: |
| 8156 | |
| 8157 | @smallexample |
| 8158 | (define_delay @var{test} |
| 8159 | [@var{delay-1} @var{annul-true-1} @var{annul-false-1} |
| 8160 | @var{delay-2} @var{annul-true-2} @var{annul-false-2} |
| 8161 | @dots{}]) |
| 8162 | @end smallexample |
| 8163 | |
| 8164 | @var{test} is an attribute test that indicates whether this |
| 8165 | @code{define_delay} applies to a particular insn. If so, the number of |
| 8166 | required delay slots is determined by the length of the vector specified |
| 8167 | as the second argument. An insn placed in delay slot @var{n} must |
| 8168 | satisfy attribute test @var{delay-n}. @var{annul-true-n} is an |
| 8169 | attribute test that specifies which insns may be annulled if the branch |
| 8170 | is true. Similarly, @var{annul-false-n} specifies which insns in the |
| 8171 | delay slot may be annulled if the branch is false. If annulling is not |
| 8172 | supported for that delay slot, @code{(nil)} should be coded. |
| 8173 | |
| 8174 | For example, in the common case where branch and call insns require |
| 8175 | a single delay slot, which may contain any insn other than a branch or |
| 8176 | call, the following would be placed in the @file{md} file: |
| 8177 | |
| 8178 | @smallexample |
| 8179 | (define_delay (eq_attr "type" "branch,call") |
| 8180 | [(eq_attr "type" "!branch,call") (nil) (nil)]) |
| 8181 | @end smallexample |
| 8182 | |
| 8183 | Multiple @code{define_delay} expressions may be specified. In this |
| 8184 | case, each such expression specifies different delay slot requirements |
| 8185 | and there must be no insn for which tests in two @code{define_delay} |
| 8186 | expressions are both true. |
| 8187 | |
| 8188 | For example, if we have a machine that requires one delay slot for branches |
| 8189 | but two for calls, no delay slot can contain a branch or call insn, |
| 8190 | and any valid insn in the delay slot for the branch can be annulled if the |
| 8191 | branch is true, we might represent this as follows: |
| 8192 | |
| 8193 | @smallexample |
| 8194 | (define_delay (eq_attr "type" "branch") |
| 8195 | [(eq_attr "type" "!branch,call") |
| 8196 | (eq_attr "type" "!branch,call") |
| 8197 | (nil)]) |
| 8198 | |
| 8199 | (define_delay (eq_attr "type" "call") |
| 8200 | [(eq_attr "type" "!branch,call") (nil) (nil) |
| 8201 | (eq_attr "type" "!branch,call") (nil) (nil)]) |
| 8202 | @end smallexample |
| 8203 | @c the above is *still* too long. --mew 4feb93 |
| 8204 | |
| 8205 | @end ifset |
| 8206 | @ifset INTERNALS |
| 8207 | @node Processor pipeline description |
| 8208 | @subsection Specifying processor pipeline description |
| 8209 | @cindex processor pipeline description |
| 8210 | @cindex processor functional units |
| 8211 | @cindex instruction latency time |
| 8212 | @cindex interlock delays |
| 8213 | @cindex data dependence delays |
| 8214 | @cindex reservation delays |
| 8215 | @cindex pipeline hazard recognizer |
| 8216 | @cindex automaton based pipeline description |
| 8217 | @cindex regular expressions |
| 8218 | @cindex deterministic finite state automaton |
| 8219 | @cindex automaton based scheduler |
| 8220 | @cindex RISC |
| 8221 | @cindex VLIW |
| 8222 | |
| 8223 | To achieve better performance, most modern processors |
| 8224 | (super-pipelined, superscalar @acronym{RISC}, and @acronym{VLIW} |
| 8225 | processors) have many @dfn{functional units} on which several |
| 8226 | instructions can be executed simultaneously. An instruction starts |
| 8227 | execution if its issue conditions are satisfied. If not, the |
| 8228 | instruction is stalled until its conditions are satisfied. Such |
| 8229 | @dfn{interlock (pipeline) delay} causes interruption of the fetching |
| 8230 | of successor instructions (or demands nop instructions, e.g.@: for some |
| 8231 | MIPS processors). |
| 8232 | |
| 8233 | There are two major kinds of interlock delays in modern processors. |
| 8234 | The first one is a data dependence delay determining @dfn{instruction |
| 8235 | latency time}. The instruction execution is not started until all |
| 8236 | source data have been evaluated by prior instructions (there are more |
| 8237 | complex cases when the instruction execution starts even when the data |
| 8238 | are not available but will be ready in given time after the |
| 8239 | instruction execution start). Taking the data dependence delays into |
| 8240 | account is simple. The data dependence (true, output, and |
| 8241 | anti-dependence) delay between two instructions is given by a |
| 8242 | constant. In most cases this approach is adequate. The second kind |
| 8243 | of interlock delays is a reservation delay. The reservation delay |
| 8244 | means that two instructions under execution will be in need of shared |
| 8245 | processors resources, i.e.@: buses, internal registers, and/or |
| 8246 | functional units, which are reserved for some time. Taking this kind |
| 8247 | of delay into account is complex especially for modern @acronym{RISC} |
| 8248 | processors. |
| 8249 | |
| 8250 | The task of exploiting more processor parallelism is solved by an |
| 8251 | instruction scheduler. For a better solution to this problem, the |
| 8252 | instruction scheduler has to have an adequate description of the |
| 8253 | processor parallelism (or @dfn{pipeline description}). GCC |
| 8254 | machine descriptions describe processor parallelism and functional |
| 8255 | unit reservations for groups of instructions with the aid of |
| 8256 | @dfn{regular expressions}. |
| 8257 | |
| 8258 | The GCC instruction scheduler uses a @dfn{pipeline hazard recognizer} to |
| 8259 | figure out the possibility of the instruction issue by the processor |
| 8260 | on a given simulated processor cycle. The pipeline hazard recognizer is |
| 8261 | automatically generated from the processor pipeline description. The |
| 8262 | pipeline hazard recognizer generated from the machine description |
| 8263 | is based on a deterministic finite state automaton (@acronym{DFA}): |
| 8264 | the instruction issue is possible if there is a transition from one |
| 8265 | automaton state to another one. This algorithm is very fast, and |
| 8266 | furthermore, its speed is not dependent on processor |
| 8267 | complexity@footnote{However, the size of the automaton depends on |
| 8268 | processor complexity. To limit this effect, machine descriptions |
| 8269 | can split orthogonal parts of the machine description among several |
| 8270 | automata: but then, since each of these must be stepped independently, |
| 8271 | this does cause a small decrease in the algorithm's performance.}. |
| 8272 | |
| 8273 | @cindex automaton based pipeline description |
| 8274 | The rest of this section describes the directives that constitute |
| 8275 | an automaton-based processor pipeline description. The order of |
| 8276 | these constructions within the machine description file is not |
| 8277 | important. |
| 8278 | |
| 8279 | @findex define_automaton |
| 8280 | @cindex pipeline hazard recognizer |
| 8281 | The following optional construction describes names of automata |
| 8282 | generated and used for the pipeline hazards recognition. Sometimes |
| 8283 | the generated finite state automaton used by the pipeline hazard |
| 8284 | recognizer is large. If we use more than one automaton and bind functional |
| 8285 | units to the automata, the total size of the automata is usually |
| 8286 | less than the size of the single automaton. If there is no one such |
| 8287 | construction, only one finite state automaton is generated. |
| 8288 | |
| 8289 | @smallexample |
| 8290 | (define_automaton @var{automata-names}) |
| 8291 | @end smallexample |
| 8292 | |
| 8293 | @var{automata-names} is a string giving names of the automata. The |
| 8294 | names are separated by commas. All the automata should have unique names. |
| 8295 | The automaton name is used in the constructions @code{define_cpu_unit} and |
| 8296 | @code{define_query_cpu_unit}. |
| 8297 | |
| 8298 | @findex define_cpu_unit |
| 8299 | @cindex processor functional units |
| 8300 | Each processor functional unit used in the description of instruction |
| 8301 | reservations should be described by the following construction. |
| 8302 | |
| 8303 | @smallexample |
| 8304 | (define_cpu_unit @var{unit-names} [@var{automaton-name}]) |
| 8305 | @end smallexample |
| 8306 | |
| 8307 | @var{unit-names} is a string giving the names of the functional units |
| 8308 | separated by commas. Don't use name @samp{nothing}, it is reserved |
| 8309 | for other goals. |
| 8310 | |
| 8311 | @var{automaton-name} is a string giving the name of the automaton with |
| 8312 | which the unit is bound. The automaton should be described in |
| 8313 | construction @code{define_automaton}. You should give |
| 8314 | @dfn{automaton-name}, if there is a defined automaton. |
| 8315 | |
| 8316 | The assignment of units to automata are constrained by the uses of the |
| 8317 | units in insn reservations. The most important constraint is: if a |
| 8318 | unit reservation is present on a particular cycle of an alternative |
| 8319 | for an insn reservation, then some unit from the same automaton must |
| 8320 | be present on the same cycle for the other alternatives of the insn |
| 8321 | reservation. The rest of the constraints are mentioned in the |
| 8322 | description of the subsequent constructions. |
| 8323 | |
| 8324 | @findex define_query_cpu_unit |
| 8325 | @cindex querying function unit reservations |
| 8326 | The following construction describes CPU functional units analogously |
| 8327 | to @code{define_cpu_unit}. The reservation of such units can be |
| 8328 | queried for an automaton state. The instruction scheduler never |
| 8329 | queries reservation of functional units for given automaton state. So |
| 8330 | as a rule, you don't need this construction. This construction could |
| 8331 | be used for future code generation goals (e.g.@: to generate |
| 8332 | @acronym{VLIW} insn templates). |
| 8333 | |
| 8334 | @smallexample |
| 8335 | (define_query_cpu_unit @var{unit-names} [@var{automaton-name}]) |
| 8336 | @end smallexample |
| 8337 | |
| 8338 | @var{unit-names} is a string giving names of the functional units |
| 8339 | separated by commas. |
| 8340 | |
| 8341 | @var{automaton-name} is a string giving the name of the automaton with |
| 8342 | which the unit is bound. |
| 8343 | |
| 8344 | @findex define_insn_reservation |
| 8345 | @cindex instruction latency time |
| 8346 | @cindex regular expressions |
| 8347 | @cindex data bypass |
| 8348 | The following construction is the major one to describe pipeline |
| 8349 | characteristics of an instruction. |
| 8350 | |
| 8351 | @smallexample |
| 8352 | (define_insn_reservation @var{insn-name} @var{default_latency} |
| 8353 | @var{condition} @var{regexp}) |
| 8354 | @end smallexample |
| 8355 | |
| 8356 | @var{default_latency} is a number giving latency time of the |
| 8357 | instruction. There is an important difference between the old |
| 8358 | description and the automaton based pipeline description. The latency |
| 8359 | time is used for all dependencies when we use the old description. In |
| 8360 | the automaton based pipeline description, the given latency time is only |
| 8361 | used for true dependencies. The cost of anti-dependencies is always |
| 8362 | zero and the cost of output dependencies is the difference between |
| 8363 | latency times of the producing and consuming insns (if the difference |
| 8364 | is negative, the cost is considered to be zero). You can always |
| 8365 | change the default costs for any description by using the target hook |
| 8366 | @code{TARGET_SCHED_ADJUST_COST} (@pxref{Scheduling}). |
| 8367 | |
| 8368 | @var{insn-name} is a string giving the internal name of the insn. The |
| 8369 | internal names are used in constructions @code{define_bypass} and in |
| 8370 | the automaton description file generated for debugging. The internal |
| 8371 | name has nothing in common with the names in @code{define_insn}. It is a |
| 8372 | good practice to use insn classes described in the processor manual. |
| 8373 | |
| 8374 | @var{condition} defines what RTL insns are described by this |
| 8375 | construction. You should remember that you will be in trouble if |
| 8376 | @var{condition} for two or more different |
| 8377 | @code{define_insn_reservation} constructions is TRUE for an insn. In |
| 8378 | this case what reservation will be used for the insn is not defined. |
| 8379 | Such cases are not checked during generation of the pipeline hazards |
| 8380 | recognizer because in general recognizing that two conditions may have |
| 8381 | the same value is quite difficult (especially if the conditions |
| 8382 | contain @code{symbol_ref}). It is also not checked during the |
| 8383 | pipeline hazard recognizer work because it would slow down the |
| 8384 | recognizer considerably. |
| 8385 | |
| 8386 | @var{regexp} is a string describing the reservation of the cpu's functional |
| 8387 | units by the instruction. The reservations are described by a regular |
| 8388 | expression according to the following syntax: |
| 8389 | |
| 8390 | @smallexample |
| 8391 | regexp = regexp "," oneof |
| 8392 | | oneof |
| 8393 | |
| 8394 | oneof = oneof "|" allof |
| 8395 | | allof |
| 8396 | |
| 8397 | allof = allof "+" repeat |
| 8398 | | repeat |
| 8399 | |
| 8400 | repeat = element "*" number |
| 8401 | | element |
| 8402 | |
| 8403 | element = cpu_function_unit_name |
| 8404 | | reservation_name |
| 8405 | | result_name |
| 8406 | | "nothing" |
| 8407 | | "(" regexp ")" |
| 8408 | @end smallexample |
| 8409 | |
| 8410 | @itemize @bullet |
| 8411 | @item |
| 8412 | @samp{,} is used for describing the start of the next cycle in |
| 8413 | the reservation. |
| 8414 | |
| 8415 | @item |
| 8416 | @samp{|} is used for describing a reservation described by the first |
| 8417 | regular expression @strong{or} a reservation described by the second |
| 8418 | regular expression @strong{or} etc. |
| 8419 | |
| 8420 | @item |
| 8421 | @samp{+} is used for describing a reservation described by the first |
| 8422 | regular expression @strong{and} a reservation described by the |
| 8423 | second regular expression @strong{and} etc. |
| 8424 | |
| 8425 | @item |
| 8426 | @samp{*} is used for convenience and simply means a sequence in which |
| 8427 | the regular expression are repeated @var{number} times with cycle |
| 8428 | advancing (see @samp{,}). |
| 8429 | |
| 8430 | @item |
| 8431 | @samp{cpu_function_unit_name} denotes reservation of the named |
| 8432 | functional unit. |
| 8433 | |
| 8434 | @item |
| 8435 | @samp{reservation_name} --- see description of construction |
| 8436 | @samp{define_reservation}. |
| 8437 | |
| 8438 | @item |
| 8439 | @samp{nothing} denotes no unit reservations. |
| 8440 | @end itemize |
| 8441 | |
| 8442 | @findex define_reservation |
| 8443 | Sometimes unit reservations for different insns contain common parts. |
| 8444 | In such case, you can simplify the pipeline description by describing |
| 8445 | the common part by the following construction |
| 8446 | |
| 8447 | @smallexample |
| 8448 | (define_reservation @var{reservation-name} @var{regexp}) |
| 8449 | @end smallexample |
| 8450 | |
| 8451 | @var{reservation-name} is a string giving name of @var{regexp}. |
| 8452 | Functional unit names and reservation names are in the same name |
| 8453 | space. So the reservation names should be different from the |
| 8454 | functional unit names and can not be the reserved name @samp{nothing}. |
| 8455 | |
| 8456 | @findex define_bypass |
| 8457 | @cindex instruction latency time |
| 8458 | @cindex data bypass |
| 8459 | The following construction is used to describe exceptions in the |
| 8460 | latency time for given instruction pair. This is so called bypasses. |
| 8461 | |
| 8462 | @smallexample |
| 8463 | (define_bypass @var{number} @var{out_insn_names} @var{in_insn_names} |
| 8464 | [@var{guard}]) |
| 8465 | @end smallexample |
| 8466 | |
| 8467 | @var{number} defines when the result generated by the instructions |
| 8468 | given in string @var{out_insn_names} will be ready for the |
| 8469 | instructions given in string @var{in_insn_names}. Each of these |
| 8470 | strings is a comma-separated list of filename-style globs and |
| 8471 | they refer to the names of @code{define_insn_reservation}s. |
| 8472 | For example: |
| 8473 | @smallexample |
| 8474 | (define_bypass 1 "cpu1_load_*, cpu1_store_*" "cpu1_load_*") |
| 8475 | @end smallexample |
| 8476 | defines a bypass between instructions that start with |
| 8477 | @samp{cpu1_load_} or @samp{cpu1_store_} and those that start with |
| 8478 | @samp{cpu1_load_}. |
| 8479 | |
| 8480 | @var{guard} is an optional string giving the name of a C function which |
| 8481 | defines an additional guard for the bypass. The function will get the |
| 8482 | two insns as parameters. If the function returns zero the bypass will |
| 8483 | be ignored for this case. The additional guard is necessary to |
| 8484 | recognize complicated bypasses, e.g.@: when the consumer is only an address |
| 8485 | of insn @samp{store} (not a stored value). |
| 8486 | |
| 8487 | If there are more one bypass with the same output and input insns, the |
| 8488 | chosen bypass is the first bypass with a guard in description whose |
| 8489 | guard function returns nonzero. If there is no such bypass, then |
| 8490 | bypass without the guard function is chosen. |
| 8491 | |
| 8492 | @findex exclusion_set |
| 8493 | @findex presence_set |
| 8494 | @findex final_presence_set |
| 8495 | @findex absence_set |
| 8496 | @findex final_absence_set |
| 8497 | @cindex VLIW |
| 8498 | @cindex RISC |
| 8499 | The following five constructions are usually used to describe |
| 8500 | @acronym{VLIW} processors, or more precisely, to describe a placement |
| 8501 | of small instructions into @acronym{VLIW} instruction slots. They |
| 8502 | can be used for @acronym{RISC} processors, too. |
| 8503 | |
| 8504 | @smallexample |
| 8505 | (exclusion_set @var{unit-names} @var{unit-names}) |
| 8506 | (presence_set @var{unit-names} @var{patterns}) |
| 8507 | (final_presence_set @var{unit-names} @var{patterns}) |
| 8508 | (absence_set @var{unit-names} @var{patterns}) |
| 8509 | (final_absence_set @var{unit-names} @var{patterns}) |
| 8510 | @end smallexample |
| 8511 | |
| 8512 | @var{unit-names} is a string giving names of functional units |
| 8513 | separated by commas. |
| 8514 | |
| 8515 | @var{patterns} is a string giving patterns of functional units |
| 8516 | separated by comma. Currently pattern is one unit or units |
| 8517 | separated by white-spaces. |
| 8518 | |
| 8519 | The first construction (@samp{exclusion_set}) means that each |
| 8520 | functional unit in the first string can not be reserved simultaneously |
| 8521 | with a unit whose name is in the second string and vice versa. For |
| 8522 | example, the construction is useful for describing processors |
| 8523 | (e.g.@: some SPARC processors) with a fully pipelined floating point |
| 8524 | functional unit which can execute simultaneously only single floating |
| 8525 | point insns or only double floating point insns. |
| 8526 | |
| 8527 | The second construction (@samp{presence_set}) means that each |
| 8528 | functional unit in the first string can not be reserved unless at |
| 8529 | least one of pattern of units whose names are in the second string is |
| 8530 | reserved. This is an asymmetric relation. For example, it is useful |
| 8531 | for description that @acronym{VLIW} @samp{slot1} is reserved after |
| 8532 | @samp{slot0} reservation. We could describe it by the following |
| 8533 | construction |
| 8534 | |
| 8535 | @smallexample |
| 8536 | (presence_set "slot1" "slot0") |
| 8537 | @end smallexample |
| 8538 | |
| 8539 | Or @samp{slot1} is reserved only after @samp{slot0} and unit @samp{b0} |
| 8540 | reservation. In this case we could write |
| 8541 | |
| 8542 | @smallexample |
| 8543 | (presence_set "slot1" "slot0 b0") |
| 8544 | @end smallexample |
| 8545 | |
| 8546 | The third construction (@samp{final_presence_set}) is analogous to |
| 8547 | @samp{presence_set}. The difference between them is when checking is |
| 8548 | done. When an instruction is issued in given automaton state |
| 8549 | reflecting all current and planned unit reservations, the automaton |
| 8550 | state is changed. The first state is a source state, the second one |
| 8551 | is a result state. Checking for @samp{presence_set} is done on the |
| 8552 | source state reservation, checking for @samp{final_presence_set} is |
| 8553 | done on the result reservation. This construction is useful to |
| 8554 | describe a reservation which is actually two subsequent reservations. |
| 8555 | For example, if we use |
| 8556 | |
| 8557 | @smallexample |
| 8558 | (presence_set "slot1" "slot0") |
| 8559 | @end smallexample |
| 8560 | |
| 8561 | the following insn will be never issued (because @samp{slot1} requires |
| 8562 | @samp{slot0} which is absent in the source state). |
| 8563 | |
| 8564 | @smallexample |
| 8565 | (define_reservation "insn_and_nop" "slot0 + slot1") |
| 8566 | @end smallexample |
| 8567 | |
| 8568 | but it can be issued if we use analogous @samp{final_presence_set}. |
| 8569 | |
| 8570 | The forth construction (@samp{absence_set}) means that each functional |
| 8571 | unit in the first string can be reserved only if each pattern of units |
| 8572 | whose names are in the second string is not reserved. This is an |
| 8573 | asymmetric relation (actually @samp{exclusion_set} is analogous to |
| 8574 | this one but it is symmetric). For example it might be useful in a |
| 8575 | @acronym{VLIW} description to say that @samp{slot0} cannot be reserved |
| 8576 | after either @samp{slot1} or @samp{slot2} have been reserved. This |
| 8577 | can be described as: |
| 8578 | |
| 8579 | @smallexample |
| 8580 | (absence_set "slot0" "slot1, slot2") |
| 8581 | @end smallexample |
| 8582 | |
| 8583 | Or @samp{slot2} can not be reserved if @samp{slot0} and unit @samp{b0} |
| 8584 | are reserved or @samp{slot1} and unit @samp{b1} are reserved. In |
| 8585 | this case we could write |
| 8586 | |
| 8587 | @smallexample |
| 8588 | (absence_set "slot2" "slot0 b0, slot1 b1") |
| 8589 | @end smallexample |
| 8590 | |
| 8591 | All functional units mentioned in a set should belong to the same |
| 8592 | automaton. |
| 8593 | |
| 8594 | The last construction (@samp{final_absence_set}) is analogous to |
| 8595 | @samp{absence_set} but checking is done on the result (state) |
| 8596 | reservation. See comments for @samp{final_presence_set}. |
| 8597 | |
| 8598 | @findex automata_option |
| 8599 | @cindex deterministic finite state automaton |
| 8600 | @cindex nondeterministic finite state automaton |
| 8601 | @cindex finite state automaton minimization |
| 8602 | You can control the generator of the pipeline hazard recognizer with |
| 8603 | the following construction. |
| 8604 | |
| 8605 | @smallexample |
| 8606 | (automata_option @var{options}) |
| 8607 | @end smallexample |
| 8608 | |
| 8609 | @var{options} is a string giving options which affect the generated |
| 8610 | code. Currently there are the following options: |
| 8611 | |
| 8612 | @itemize @bullet |
| 8613 | @item |
| 8614 | @dfn{no-minimization} makes no minimization of the automaton. This is |
| 8615 | only worth to do when we are debugging the description and need to |
| 8616 | look more accurately at reservations of states. |
| 8617 | |
| 8618 | @item |
| 8619 | @dfn{time} means printing time statistics about the generation of |
| 8620 | automata. |
| 8621 | |
| 8622 | @item |
| 8623 | @dfn{stats} means printing statistics about the generated automata |
| 8624 | such as the number of DFA states, NDFA states and arcs. |
| 8625 | |
| 8626 | @item |
| 8627 | @dfn{v} means a generation of the file describing the result automata. |
| 8628 | The file has suffix @samp{.dfa} and can be used for the description |
| 8629 | verification and debugging. |
| 8630 | |
| 8631 | @item |
| 8632 | @dfn{w} means a generation of warning instead of error for |
| 8633 | non-critical errors. |
| 8634 | |
| 8635 | @item |
| 8636 | @dfn{no-comb-vect} prevents the automaton generator from generating |
| 8637 | two data structures and comparing them for space efficiency. Using |
| 8638 | a comb vector to represent transitions may be better, but it can be |
| 8639 | very expensive to construct. This option is useful if the build |
| 8640 | process spends an unacceptably long time in genautomata. |
| 8641 | |
| 8642 | @item |
| 8643 | @dfn{ndfa} makes nondeterministic finite state automata. This affects |
| 8644 | the treatment of operator @samp{|} in the regular expressions. The |
| 8645 | usual treatment of the operator is to try the first alternative and, |
| 8646 | if the reservation is not possible, the second alternative. The |
| 8647 | nondeterministic treatment means trying all alternatives, some of them |
| 8648 | may be rejected by reservations in the subsequent insns. |
| 8649 | |
| 8650 | @item |
| 8651 | @dfn{collapse-ndfa} modifies the behaviour of the generator when |
| 8652 | producing an automaton. An additional state transition to collapse a |
| 8653 | nondeterministic @acronym{NDFA} state to a deterministic @acronym{DFA} |
| 8654 | state is generated. It can be triggered by passing @code{const0_rtx} to |
| 8655 | state_transition. In such an automaton, cycle advance transitions are |
| 8656 | available only for these collapsed states. This option is useful for |
| 8657 | ports that want to use the @code{ndfa} option, but also want to use |
| 8658 | @code{define_query_cpu_unit} to assign units to insns issued in a cycle. |
| 8659 | |
| 8660 | @item |
| 8661 | @dfn{progress} means output of a progress bar showing how many states |
| 8662 | were generated so far for automaton being processed. This is useful |
| 8663 | during debugging a @acronym{DFA} description. If you see too many |
| 8664 | generated states, you could interrupt the generator of the pipeline |
| 8665 | hazard recognizer and try to figure out a reason for generation of the |
| 8666 | huge automaton. |
| 8667 | @end itemize |
| 8668 | |
| 8669 | As an example, consider a superscalar @acronym{RISC} machine which can |
| 8670 | issue three insns (two integer insns and one floating point insn) on |
| 8671 | the cycle but can finish only two insns. To describe this, we define |
| 8672 | the following functional units. |
| 8673 | |
| 8674 | @smallexample |
| 8675 | (define_cpu_unit "i0_pipeline, i1_pipeline, f_pipeline") |
| 8676 | (define_cpu_unit "port0, port1") |
| 8677 | @end smallexample |
| 8678 | |
| 8679 | All simple integer insns can be executed in any integer pipeline and |
| 8680 | their result is ready in two cycles. The simple integer insns are |
| 8681 | issued into the first pipeline unless it is reserved, otherwise they |
| 8682 | are issued into the second pipeline. Integer division and |
| 8683 | multiplication insns can be executed only in the second integer |
| 8684 | pipeline and their results are ready correspondingly in 8 and 4 |
| 8685 | cycles. The integer division is not pipelined, i.e.@: the subsequent |
| 8686 | integer division insn can not be issued until the current division |
| 8687 | insn finished. Floating point insns are fully pipelined and their |
| 8688 | results are ready in 3 cycles. Where the result of a floating point |
| 8689 | insn is used by an integer insn, an additional delay of one cycle is |
| 8690 | incurred. To describe all of this we could specify |
| 8691 | |
| 8692 | @smallexample |
| 8693 | (define_cpu_unit "div") |
| 8694 | |
| 8695 | (define_insn_reservation "simple" 2 (eq_attr "type" "int") |
| 8696 | "(i0_pipeline | i1_pipeline), (port0 | port1)") |
| 8697 | |
| 8698 | (define_insn_reservation "mult" 4 (eq_attr "type" "mult") |
| 8699 | "i1_pipeline, nothing*2, (port0 | port1)") |
| 8700 | |
| 8701 | (define_insn_reservation "div" 8 (eq_attr "type" "div") |
| 8702 | "i1_pipeline, div*7, div + (port0 | port1)") |
| 8703 | |
| 8704 | (define_insn_reservation "float" 3 (eq_attr "type" "float") |
| 8705 | "f_pipeline, nothing, (port0 | port1)) |
| 8706 | |
| 8707 | (define_bypass 4 "float" "simple,mult,div") |
| 8708 | @end smallexample |
| 8709 | |
| 8710 | To simplify the description we could describe the following reservation |
| 8711 | |
| 8712 | @smallexample |
| 8713 | (define_reservation "finish" "port0|port1") |
| 8714 | @end smallexample |
| 8715 | |
| 8716 | and use it in all @code{define_insn_reservation} as in the following |
| 8717 | construction |
| 8718 | |
| 8719 | @smallexample |
| 8720 | (define_insn_reservation "simple" 2 (eq_attr "type" "int") |
| 8721 | "(i0_pipeline | i1_pipeline), finish") |
| 8722 | @end smallexample |
| 8723 | |
| 8724 | |
| 8725 | @end ifset |
| 8726 | @ifset INTERNALS |
| 8727 | @node Conditional Execution |
| 8728 | @section Conditional Execution |
| 8729 | @cindex conditional execution |
| 8730 | @cindex predication |
| 8731 | |
| 8732 | A number of architectures provide for some form of conditional |
| 8733 | execution, or predication. The hallmark of this feature is the |
| 8734 | ability to nullify most of the instructions in the instruction set. |
| 8735 | When the instruction set is large and not entirely symmetric, it |
| 8736 | can be quite tedious to describe these forms directly in the |
| 8737 | @file{.md} file. An alternative is the @code{define_cond_exec} template. |
| 8738 | |
| 8739 | @findex define_cond_exec |
| 8740 | @smallexample |
| 8741 | (define_cond_exec |
| 8742 | [@var{predicate-pattern}] |
| 8743 | "@var{condition}" |
| 8744 | "@var{output-template}") |
| 8745 | @end smallexample |
| 8746 | |
| 8747 | @var{predicate-pattern} is the condition that must be true for the |
| 8748 | insn to be executed at runtime and should match a relational operator. |
| 8749 | One can use @code{match_operator} to match several relational operators |
| 8750 | at once. Any @code{match_operand} operands must have no more than one |
| 8751 | alternative. |
| 8752 | |
| 8753 | @var{condition} is a C expression that must be true for the generated |
| 8754 | pattern to match. |
| 8755 | |
| 8756 | @findex current_insn_predicate |
| 8757 | @var{output-template} is a string similar to the @code{define_insn} |
| 8758 | output template (@pxref{Output Template}), except that the @samp{*} |
| 8759 | and @samp{@@} special cases do not apply. This is only useful if the |
| 8760 | assembly text for the predicate is a simple prefix to the main insn. |
| 8761 | In order to handle the general case, there is a global variable |
| 8762 | @code{current_insn_predicate} that will contain the entire predicate |
| 8763 | if the current insn is predicated, and will otherwise be @code{NULL}. |
| 8764 | |
| 8765 | When @code{define_cond_exec} is used, an implicit reference to |
| 8766 | the @code{predicable} instruction attribute is made. |
| 8767 | @xref{Insn Attributes}. This attribute must be a boolean (i.e.@: have |
| 8768 | exactly two elements in its @var{list-of-values}), with the possible |
| 8769 | values being @code{no} and @code{yes}. The default and all uses in |
| 8770 | the insns must be a simple constant, not a complex expressions. It |
| 8771 | may, however, depend on the alternative, by using a comma-separated |
| 8772 | list of values. If that is the case, the port should also define an |
| 8773 | @code{enabled} attribute (@pxref{Disable Insn Alternatives}), which |
| 8774 | should also allow only @code{no} and @code{yes} as its values. |
| 8775 | |
| 8776 | For each @code{define_insn} for which the @code{predicable} |
| 8777 | attribute is true, a new @code{define_insn} pattern will be |
| 8778 | generated that matches a predicated version of the instruction. |
| 8779 | For example, |
| 8780 | |
| 8781 | @smallexample |
| 8782 | (define_insn "addsi" |
| 8783 | [(set (match_operand:SI 0 "register_operand" "r") |
| 8784 | (plus:SI (match_operand:SI 1 "register_operand" "r") |
| 8785 | (match_operand:SI 2 "register_operand" "r")))] |
| 8786 | "@var{test1}" |
| 8787 | "add %2,%1,%0") |
| 8788 | |
| 8789 | (define_cond_exec |
| 8790 | [(ne (match_operand:CC 0 "register_operand" "c") |
| 8791 | (const_int 0))] |
| 8792 | "@var{test2}" |
| 8793 | "(%0)") |
| 8794 | @end smallexample |
| 8795 | |
| 8796 | @noindent |
| 8797 | generates a new pattern |
| 8798 | |
| 8799 | @smallexample |
| 8800 | (define_insn "" |
| 8801 | [(cond_exec |
| 8802 | (ne (match_operand:CC 3 "register_operand" "c") (const_int 0)) |
| 8803 | (set (match_operand:SI 0 "register_operand" "r") |
| 8804 | (plus:SI (match_operand:SI 1 "register_operand" "r") |
| 8805 | (match_operand:SI 2 "register_operand" "r"))))] |
| 8806 | "(@var{test2}) && (@var{test1})" |
| 8807 | "(%3) add %2,%1,%0") |
| 8808 | @end smallexample |
| 8809 | |
| 8810 | @end ifset |
| 8811 | @ifset INTERNALS |
| 8812 | @node Constant Definitions |
| 8813 | @section Constant Definitions |
| 8814 | @cindex constant definitions |
| 8815 | @findex define_constants |
| 8816 | |
| 8817 | Using literal constants inside instruction patterns reduces legibility and |
| 8818 | can be a maintenance problem. |
| 8819 | |
| 8820 | To overcome this problem, you may use the @code{define_constants} |
| 8821 | expression. It contains a vector of name-value pairs. From that |
| 8822 | point on, wherever any of the names appears in the MD file, it is as |
| 8823 | if the corresponding value had been written instead. You may use |
| 8824 | @code{define_constants} multiple times; each appearance adds more |
| 8825 | constants to the table. It is an error to redefine a constant with |
| 8826 | a different value. |
| 8827 | |
| 8828 | To come back to the a29k load multiple example, instead of |
| 8829 | |
| 8830 | @smallexample |
| 8831 | (define_insn "" |
| 8832 | [(match_parallel 0 "load_multiple_operation" |
| 8833 | [(set (match_operand:SI 1 "gpc_reg_operand" "=r") |
| 8834 | (match_operand:SI 2 "memory_operand" "m")) |
| 8835 | (use (reg:SI 179)) |
| 8836 | (clobber (reg:SI 179))])] |
| 8837 | "" |
| 8838 | "loadm 0,0,%1,%2") |
| 8839 | @end smallexample |
| 8840 | |
| 8841 | You could write: |
| 8842 | |
| 8843 | @smallexample |
| 8844 | (define_constants [ |
| 8845 | (R_BP 177) |
| 8846 | (R_FC 178) |
| 8847 | (R_CR 179) |
| 8848 | (R_Q 180) |
| 8849 | ]) |
| 8850 | |
| 8851 | (define_insn "" |
| 8852 | [(match_parallel 0 "load_multiple_operation" |
| 8853 | [(set (match_operand:SI 1 "gpc_reg_operand" "=r") |
| 8854 | (match_operand:SI 2 "memory_operand" "m")) |
| 8855 | (use (reg:SI R_CR)) |
| 8856 | (clobber (reg:SI R_CR))])] |
| 8857 | "" |
| 8858 | "loadm 0,0,%1,%2") |
| 8859 | @end smallexample |
| 8860 | |
| 8861 | The constants that are defined with a define_constant are also output |
| 8862 | in the insn-codes.h header file as #defines. |
| 8863 | |
| 8864 | @cindex enumerations |
| 8865 | @findex define_c_enum |
| 8866 | You can also use the machine description file to define enumerations. |
| 8867 | Like the constants defined by @code{define_constant}, these enumerations |
| 8868 | are visible to both the machine description file and the main C code. |
| 8869 | |
| 8870 | The syntax is as follows: |
| 8871 | |
| 8872 | @smallexample |
| 8873 | (define_c_enum "@var{name}" [ |
| 8874 | @var{value0} |
| 8875 | @var{value1} |
| 8876 | @dots{} |
| 8877 | @var{valuen} |
| 8878 | ]) |
| 8879 | @end smallexample |
| 8880 | |
| 8881 | This definition causes the equivalent of the following C code to appear |
| 8882 | in @file{insn-constants.h}: |
| 8883 | |
| 8884 | @smallexample |
| 8885 | enum @var{name} @{ |
| 8886 | @var{value0} = 0, |
| 8887 | @var{value1} = 1, |
| 8888 | @dots{} |
| 8889 | @var{valuen} = @var{n} |
| 8890 | @}; |
| 8891 | #define NUM_@var{cname}_VALUES (@var{n} + 1) |
| 8892 | @end smallexample |
| 8893 | |
| 8894 | where @var{cname} is the capitalized form of @var{name}. |
| 8895 | It also makes each @var{valuei} available in the machine description |
| 8896 | file, just as if it had been declared with: |
| 8897 | |
| 8898 | @smallexample |
| 8899 | (define_constants [(@var{valuei} @var{i})]) |
| 8900 | @end smallexample |
| 8901 | |
| 8902 | Each @var{valuei} is usually an upper-case identifier and usually |
| 8903 | begins with @var{cname}. |
| 8904 | |
| 8905 | You can split the enumeration definition into as many statements as |
| 8906 | you like. The above example is directly equivalent to: |
| 8907 | |
| 8908 | @smallexample |
| 8909 | (define_c_enum "@var{name}" [@var{value0}]) |
| 8910 | (define_c_enum "@var{name}" [@var{value1}]) |
| 8911 | @dots{} |
| 8912 | (define_c_enum "@var{name}" [@var{valuen}]) |
| 8913 | @end smallexample |
| 8914 | |
| 8915 | Splitting the enumeration helps to improve the modularity of each |
| 8916 | individual @code{.md} file. For example, if a port defines its |
| 8917 | synchronization instructions in a separate @file{sync.md} file, |
| 8918 | it is convenient to define all synchronization-specific enumeration |
| 8919 | values in @file{sync.md} rather than in the main @file{.md} file. |
| 8920 | |
| 8921 | Some enumeration names have special significance to GCC: |
| 8922 | |
| 8923 | @table @code |
| 8924 | @item unspecv |
| 8925 | @findex unspec_volatile |
| 8926 | If an enumeration called @code{unspecv} is defined, GCC will use it |
| 8927 | when printing out @code{unspec_volatile} expressions. For example: |
| 8928 | |
| 8929 | @smallexample |
| 8930 | (define_c_enum "unspecv" [ |
| 8931 | UNSPECV_BLOCKAGE |
| 8932 | ]) |
| 8933 | @end smallexample |
| 8934 | |
| 8935 | causes GCC to print @samp{(unspec_volatile @dots{} 0)} as: |
| 8936 | |
| 8937 | @smallexample |
| 8938 | (unspec_volatile ... UNSPECV_BLOCKAGE) |
| 8939 | @end smallexample |
| 8940 | |
| 8941 | @item unspec |
| 8942 | @findex unspec |
| 8943 | If an enumeration called @code{unspec} is defined, GCC will use |
| 8944 | it when printing out @code{unspec} expressions. GCC will also use |
| 8945 | it when printing out @code{unspec_volatile} expressions unless an |
| 8946 | @code{unspecv} enumeration is also defined. You can therefore |
| 8947 | decide whether to keep separate enumerations for volatile and |
| 8948 | non-volatile expressions or whether to use the same enumeration |
| 8949 | for both. |
| 8950 | @end table |
| 8951 | |
| 8952 | @findex define_enum |
| 8953 | @anchor{define_enum} |
| 8954 | Another way of defining an enumeration is to use @code{define_enum}: |
| 8955 | |
| 8956 | @smallexample |
| 8957 | (define_enum "@var{name}" [ |
| 8958 | @var{value0} |
| 8959 | @var{value1} |
| 8960 | @dots{} |
| 8961 | @var{valuen} |
| 8962 | ]) |
| 8963 | @end smallexample |
| 8964 | |
| 8965 | This directive implies: |
| 8966 | |
| 8967 | @smallexample |
| 8968 | (define_c_enum "@var{name}" [ |
| 8969 | @var{cname}_@var{cvalue0} |
| 8970 | @var{cname}_@var{cvalue1} |
| 8971 | @dots{} |
| 8972 | @var{cname}_@var{cvaluen} |
| 8973 | ]) |
| 8974 | @end smallexample |
| 8975 | |
| 8976 | @findex define_enum_attr |
| 8977 | where @var{cvaluei} is the capitalized form of @var{valuei}. |
| 8978 | However, unlike @code{define_c_enum}, the enumerations defined |
| 8979 | by @code{define_enum} can be used in attribute specifications |
| 8980 | (@pxref{define_enum_attr}). |
| 8981 | @end ifset |
| 8982 | @ifset INTERNALS |
| 8983 | @node Iterators |
| 8984 | @section Iterators |
| 8985 | @cindex iterators in @file{.md} files |
| 8986 | |
| 8987 | Ports often need to define similar patterns for more than one machine |
| 8988 | mode or for more than one rtx code. GCC provides some simple iterator |
| 8989 | facilities to make this process easier. |
| 8990 | |
| 8991 | @menu |
| 8992 | * Mode Iterators:: Generating variations of patterns for different modes. |
| 8993 | * Code Iterators:: Doing the same for codes. |
| 8994 | * Int Iterators:: Doing the same for integers. |
| 8995 | @end menu |
| 8996 | |
| 8997 | @node Mode Iterators |
| 8998 | @subsection Mode Iterators |
| 8999 | @cindex mode iterators in @file{.md} files |
| 9000 | |
| 9001 | Ports often need to define similar patterns for two or more different modes. |
| 9002 | For example: |
| 9003 | |
| 9004 | @itemize @bullet |
| 9005 | @item |
| 9006 | If a processor has hardware support for both single and double |
| 9007 | floating-point arithmetic, the @code{SFmode} patterns tend to be |
| 9008 | very similar to the @code{DFmode} ones. |
| 9009 | |
| 9010 | @item |
| 9011 | If a port uses @code{SImode} pointers in one configuration and |
| 9012 | @code{DImode} pointers in another, it will usually have very similar |
| 9013 | @code{SImode} and @code{DImode} patterns for manipulating pointers. |
| 9014 | @end itemize |
| 9015 | |
| 9016 | Mode iterators allow several patterns to be instantiated from one |
| 9017 | @file{.md} file template. They can be used with any type of |
| 9018 | rtx-based construct, such as a @code{define_insn}, |
| 9019 | @code{define_split}, or @code{define_peephole2}. |
| 9020 | |
| 9021 | @menu |
| 9022 | * Defining Mode Iterators:: Defining a new mode iterator. |
| 9023 | * Substitutions:: Combining mode iterators with substitutions |
| 9024 | * Examples:: Examples |
| 9025 | @end menu |
| 9026 | |
| 9027 | @node Defining Mode Iterators |
| 9028 | @subsubsection Defining Mode Iterators |
| 9029 | @findex define_mode_iterator |
| 9030 | |
| 9031 | The syntax for defining a mode iterator is: |
| 9032 | |
| 9033 | @smallexample |
| 9034 | (define_mode_iterator @var{name} [(@var{mode1} "@var{cond1}") @dots{} (@var{moden} "@var{condn}")]) |
| 9035 | @end smallexample |
| 9036 | |
| 9037 | This allows subsequent @file{.md} file constructs to use the mode suffix |
| 9038 | @code{:@var{name}}. Every construct that does so will be expanded |
| 9039 | @var{n} times, once with every use of @code{:@var{name}} replaced by |
| 9040 | @code{:@var{mode1}}, once with every use replaced by @code{:@var{mode2}}, |
| 9041 | and so on. In the expansion for a particular @var{modei}, every |
| 9042 | C condition will also require that @var{condi} be true. |
| 9043 | |
| 9044 | For example: |
| 9045 | |
| 9046 | @smallexample |
| 9047 | (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) |
| 9048 | @end smallexample |
| 9049 | |
| 9050 | defines a new mode suffix @code{:P}. Every construct that uses |
| 9051 | @code{:P} will be expanded twice, once with every @code{:P} replaced |
| 9052 | by @code{:SI} and once with every @code{:P} replaced by @code{:DI}. |
| 9053 | The @code{:SI} version will only apply if @code{Pmode == SImode} and |
| 9054 | the @code{:DI} version will only apply if @code{Pmode == DImode}. |
| 9055 | |
| 9056 | As with other @file{.md} conditions, an empty string is treated |
| 9057 | as ``always true''. @code{(@var{mode} "")} can also be abbreviated |
| 9058 | to @code{@var{mode}}. For example: |
| 9059 | |
| 9060 | @smallexample |
| 9061 | (define_mode_iterator GPR [SI (DI "TARGET_64BIT")]) |
| 9062 | @end smallexample |
| 9063 | |
| 9064 | means that the @code{:DI} expansion only applies if @code{TARGET_64BIT} |
| 9065 | but that the @code{:SI} expansion has no such constraint. |
| 9066 | |
| 9067 | Iterators are applied in the order they are defined. This can be |
| 9068 | significant if two iterators are used in a construct that requires |
| 9069 | substitutions. @xref{Substitutions}. |
| 9070 | |
| 9071 | @node Substitutions |
| 9072 | @subsubsection Substitution in Mode Iterators |
| 9073 | @findex define_mode_attr |
| 9074 | |
| 9075 | If an @file{.md} file construct uses mode iterators, each version of the |
| 9076 | construct will often need slightly different strings or modes. For |
| 9077 | example: |
| 9078 | |
| 9079 | @itemize @bullet |
| 9080 | @item |
| 9081 | When a @code{define_expand} defines several @code{add@var{m}3} patterns |
| 9082 | (@pxref{Standard Names}), each expander will need to use the |
| 9083 | appropriate mode name for @var{m}. |
| 9084 | |
| 9085 | @item |
| 9086 | When a @code{define_insn} defines several instruction patterns, |
| 9087 | each instruction will often use a different assembler mnemonic. |
| 9088 | |
| 9089 | @item |
| 9090 | When a @code{define_insn} requires operands with different modes, |
| 9091 | using an iterator for one of the operand modes usually requires a specific |
| 9092 | mode for the other operand(s). |
| 9093 | @end itemize |
| 9094 | |
| 9095 | GCC supports such variations through a system of ``mode attributes''. |
| 9096 | There are two standard attributes: @code{mode}, which is the name of |
| 9097 | the mode in lower case, and @code{MODE}, which is the same thing in |
| 9098 | upper case. You can define other attributes using: |
| 9099 | |
| 9100 | @smallexample |
| 9101 | (define_mode_attr @var{name} [(@var{mode1} "@var{value1}") @dots{} (@var{moden} "@var{valuen}")]) |
| 9102 | @end smallexample |
| 9103 | |
| 9104 | where @var{name} is the name of the attribute and @var{valuei} |
| 9105 | is the value associated with @var{modei}. |
| 9106 | |
| 9107 | When GCC replaces some @var{:iterator} with @var{:mode}, it will scan |
| 9108 | each string and mode in the pattern for sequences of the form |
| 9109 | @code{<@var{iterator}:@var{attr}>}, where @var{attr} is the name of a |
| 9110 | mode attribute. If the attribute is defined for @var{mode}, the whole |
| 9111 | @code{<@dots{}>} sequence will be replaced by the appropriate attribute |
| 9112 | value. |
| 9113 | |
| 9114 | For example, suppose an @file{.md} file has: |
| 9115 | |
| 9116 | @smallexample |
| 9117 | (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) |
| 9118 | (define_mode_attr load [(SI "lw") (DI "ld")]) |
| 9119 | @end smallexample |
| 9120 | |
| 9121 | If one of the patterns that uses @code{:P} contains the string |
| 9122 | @code{"<P:load>\t%0,%1"}, the @code{SI} version of that pattern |
| 9123 | will use @code{"lw\t%0,%1"} and the @code{DI} version will use |
| 9124 | @code{"ld\t%0,%1"}. |
| 9125 | |
| 9126 | Here is an example of using an attribute for a mode: |
| 9127 | |
| 9128 | @smallexample |
| 9129 | (define_mode_iterator LONG [SI DI]) |
| 9130 | (define_mode_attr SHORT [(SI "HI") (DI "SI")]) |
| 9131 | (define_insn @dots{} |
| 9132 | (sign_extend:LONG (match_operand:<LONG:SHORT> @dots{})) @dots{}) |
| 9133 | @end smallexample |
| 9134 | |
| 9135 | The @code{@var{iterator}:} prefix may be omitted, in which case the |
| 9136 | substitution will be attempted for every iterator expansion. |
| 9137 | |
| 9138 | @node Examples |
| 9139 | @subsubsection Mode Iterator Examples |
| 9140 | |
| 9141 | Here is an example from the MIPS port. It defines the following |
| 9142 | modes and attributes (among others): |
| 9143 | |
| 9144 | @smallexample |
| 9145 | (define_mode_iterator GPR [SI (DI "TARGET_64BIT")]) |
| 9146 | (define_mode_attr d [(SI "") (DI "d")]) |
| 9147 | @end smallexample |
| 9148 | |
| 9149 | and uses the following template to define both @code{subsi3} |
| 9150 | and @code{subdi3}: |
| 9151 | |
| 9152 | @smallexample |
| 9153 | (define_insn "sub<mode>3" |
| 9154 | [(set (match_operand:GPR 0 "register_operand" "=d") |
| 9155 | (minus:GPR (match_operand:GPR 1 "register_operand" "d") |
| 9156 | (match_operand:GPR 2 "register_operand" "d")))] |
| 9157 | "" |
| 9158 | "<d>subu\t%0,%1,%2" |
| 9159 | [(set_attr "type" "arith") |
| 9160 | (set_attr "mode" "<MODE>")]) |
| 9161 | @end smallexample |
| 9162 | |
| 9163 | This is exactly equivalent to: |
| 9164 | |
| 9165 | @smallexample |
| 9166 | (define_insn "subsi3" |
| 9167 | [(set (match_operand:SI 0 "register_operand" "=d") |
| 9168 | (minus:SI (match_operand:SI 1 "register_operand" "d") |
| 9169 | (match_operand:SI 2 "register_operand" "d")))] |
| 9170 | "" |
| 9171 | "subu\t%0,%1,%2" |
| 9172 | [(set_attr "type" "arith") |
| 9173 | (set_attr "mode" "SI")]) |
| 9174 | |
| 9175 | (define_insn "subdi3" |
| 9176 | [(set (match_operand:DI 0 "register_operand" "=d") |
| 9177 | (minus:DI (match_operand:DI 1 "register_operand" "d") |
| 9178 | (match_operand:DI 2 "register_operand" "d")))] |
| 9179 | "" |
| 9180 | "dsubu\t%0,%1,%2" |
| 9181 | [(set_attr "type" "arith") |
| 9182 | (set_attr "mode" "DI")]) |
| 9183 | @end smallexample |
| 9184 | |
| 9185 | @node Code Iterators |
| 9186 | @subsection Code Iterators |
| 9187 | @cindex code iterators in @file{.md} files |
| 9188 | @findex define_code_iterator |
| 9189 | @findex define_code_attr |
| 9190 | |
| 9191 | Code iterators operate in a similar way to mode iterators. @xref{Mode Iterators}. |
| 9192 | |
| 9193 | The construct: |
| 9194 | |
| 9195 | @smallexample |
| 9196 | (define_code_iterator @var{name} [(@var{code1} "@var{cond1}") @dots{} (@var{coden} "@var{condn}")]) |
| 9197 | @end smallexample |
| 9198 | |
| 9199 | defines a pseudo rtx code @var{name} that can be instantiated as |
| 9200 | @var{codei} if condition @var{condi} is true. Each @var{codei} |
| 9201 | must have the same rtx format. @xref{RTL Classes}. |
| 9202 | |
| 9203 | As with mode iterators, each pattern that uses @var{name} will be |
| 9204 | expanded @var{n} times, once with all uses of @var{name} replaced by |
| 9205 | @var{code1}, once with all uses replaced by @var{code2}, and so on. |
| 9206 | @xref{Defining Mode Iterators}. |
| 9207 | |
| 9208 | It is possible to define attributes for codes as well as for modes. |
| 9209 | There are two standard code attributes: @code{code}, the name of the |
| 9210 | code in lower case, and @code{CODE}, the name of the code in upper case. |
| 9211 | Other attributes are defined using: |
| 9212 | |
| 9213 | @smallexample |
| 9214 | (define_code_attr @var{name} [(@var{code1} "@var{value1}") @dots{} (@var{coden} "@var{valuen}")]) |
| 9215 | @end smallexample |
| 9216 | |
| 9217 | Here's an example of code iterators in action, taken from the MIPS port: |
| 9218 | |
| 9219 | @smallexample |
| 9220 | (define_code_iterator any_cond [unordered ordered unlt unge uneq ltgt unle ungt |
| 9221 | eq ne gt ge lt le gtu geu ltu leu]) |
| 9222 | |
| 9223 | (define_expand "b<code>" |
| 9224 | [(set (pc) |
| 9225 | (if_then_else (any_cond:CC (cc0) |
| 9226 | (const_int 0)) |
| 9227 | (label_ref (match_operand 0 "")) |
| 9228 | (pc)))] |
| 9229 | "" |
| 9230 | @{ |
| 9231 | gen_conditional_branch (operands, <CODE>); |
| 9232 | DONE; |
| 9233 | @}) |
| 9234 | @end smallexample |
| 9235 | |
| 9236 | This is equivalent to: |
| 9237 | |
| 9238 | @smallexample |
| 9239 | (define_expand "bunordered" |
| 9240 | [(set (pc) |
| 9241 | (if_then_else (unordered:CC (cc0) |
| 9242 | (const_int 0)) |
| 9243 | (label_ref (match_operand 0 "")) |
| 9244 | (pc)))] |
| 9245 | "" |
| 9246 | @{ |
| 9247 | gen_conditional_branch (operands, UNORDERED); |
| 9248 | DONE; |
| 9249 | @}) |
| 9250 | |
| 9251 | (define_expand "bordered" |
| 9252 | [(set (pc) |
| 9253 | (if_then_else (ordered:CC (cc0) |
| 9254 | (const_int 0)) |
| 9255 | (label_ref (match_operand 0 "")) |
| 9256 | (pc)))] |
| 9257 | "" |
| 9258 | @{ |
| 9259 | gen_conditional_branch (operands, ORDERED); |
| 9260 | DONE; |
| 9261 | @}) |
| 9262 | |
| 9263 | @dots{} |
| 9264 | @end smallexample |
| 9265 | |
| 9266 | @node Int Iterators |
| 9267 | @subsection Int Iterators |
| 9268 | @cindex int iterators in @file{.md} files |
| 9269 | @findex define_int_iterator |
| 9270 | @findex define_int_attr |
| 9271 | |
| 9272 | Int iterators operate in a similar way to code iterators. @xref{Code Iterators}. |
| 9273 | |
| 9274 | The construct: |
| 9275 | |
| 9276 | @smallexample |
| 9277 | (define_int_iterator @var{name} [(@var{int1} "@var{cond1}") @dots{} (@var{intn} "@var{condn}")]) |
| 9278 | @end smallexample |
| 9279 | |
| 9280 | defines a pseudo integer constant @var{name} that can be instantiated as |
| 9281 | @var{inti} if condition @var{condi} is true. Each @var{int} |
| 9282 | must have the same rtx format. @xref{RTL Classes}. Int iterators can appear |
| 9283 | in only those rtx fields that have 'i' as the specifier. This means that |
| 9284 | each @var{int} has to be a constant defined using define_constant or |
| 9285 | define_c_enum. |
| 9286 | |
| 9287 | As with mode and code iterators, each pattern that uses @var{name} will be |
| 9288 | expanded @var{n} times, once with all uses of @var{name} replaced by |
| 9289 | @var{int1}, once with all uses replaced by @var{int2}, and so on. |
| 9290 | @xref{Defining Mode Iterators}. |
| 9291 | |
| 9292 | It is possible to define attributes for ints as well as for codes and modes. |
| 9293 | Attributes are defined using: |
| 9294 | |
| 9295 | @smallexample |
| 9296 | (define_int_attr @var{name} [(@var{int1} "@var{value1}") @dots{} (@var{intn} "@var{valuen}")]) |
| 9297 | @end smallexample |
| 9298 | |
| 9299 | Here's an example of int iterators in action, taken from the ARM port: |
| 9300 | |
| 9301 | @smallexample |
| 9302 | (define_int_iterator QABSNEG [UNSPEC_VQABS UNSPEC_VQNEG]) |
| 9303 | |
| 9304 | (define_int_attr absneg [(UNSPEC_VQABS "abs") (UNSPEC_VQNEG "neg")]) |
| 9305 | |
| 9306 | (define_insn "neon_vq<absneg><mode>" |
| 9307 | [(set (match_operand:VDQIW 0 "s_register_operand" "=w") |
| 9308 | (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") |
| 9309 | (match_operand:SI 2 "immediate_operand" "i")] |
| 9310 | QABSNEG))] |
| 9311 | "TARGET_NEON" |
| 9312 | "vq<absneg>.<V_s_elem>\t%<V_reg>0, %<V_reg>1" |
| 9313 | [(set_attr "neon_type" "neon_vqneg_vqabs")] |
| 9314 | ) |
| 9315 | |
| 9316 | @end smallexample |
| 9317 | |
| 9318 | This is equivalent to: |
| 9319 | |
| 9320 | @smallexample |
| 9321 | (define_insn "neon_vqabs<mode>" |
| 9322 | [(set (match_operand:VDQIW 0 "s_register_operand" "=w") |
| 9323 | (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") |
| 9324 | (match_operand:SI 2 "immediate_operand" "i")] |
| 9325 | UNSPEC_VQABS))] |
| 9326 | "TARGET_NEON" |
| 9327 | "vqabs.<V_s_elem>\t%<V_reg>0, %<V_reg>1" |
| 9328 | [(set_attr "neon_type" "neon_vqneg_vqabs")] |
| 9329 | ) |
| 9330 | |
| 9331 | (define_insn "neon_vqneg<mode>" |
| 9332 | [(set (match_operand:VDQIW 0 "s_register_operand" "=w") |
| 9333 | (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") |
| 9334 | (match_operand:SI 2 "immediate_operand" "i")] |
| 9335 | UNSPEC_VQNEG))] |
| 9336 | "TARGET_NEON" |
| 9337 | "vqneg.<V_s_elem>\t%<V_reg>0, %<V_reg>1" |
| 9338 | [(set_attr "neon_type" "neon_vqneg_vqabs")] |
| 9339 | ) |
| 9340 | |
| 9341 | @end smallexample |
| 9342 | |
| 9343 | @end ifset |