| <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> |
| <html> |
| <!-- Copyright (C) 1988-2015 Free Software Foundation, Inc. |
| |
| Permission is granted to copy, distribute and/or modify this document |
| under the terms of the GNU Free Documentation License, Version 1.3 or |
| any later version published by the Free Software Foundation; with the |
| Invariant Sections being "Funding Free Software", the Front-Cover |
| Texts being (a) (see below), and with the Back-Cover Texts being (b) |
| (see below). A copy of the license is included in the section entitled |
| "GNU Free Documentation License". |
| |
| (a) The FSF's Front-Cover Text is: |
| |
| A GNU Manual |
| |
| (b) The FSF's Back-Cover Text is: |
| |
| You have freedom to copy and modify this GNU Manual, like GNU |
| software. Copies published by the Free Software Foundation raise |
| funds for GNU development. --> |
| <!-- Created by GNU Texinfo 5.2, http://www.gnu.org/software/texinfo/ --> |
| <head> |
| <title>GNU Compiler Collection (GCC) Internals: Simple Constraints</title> |
| |
| <meta name="description" content="GNU Compiler Collection (GCC) Internals: Simple Constraints"> |
| <meta name="keywords" content="GNU Compiler Collection (GCC) Internals: Simple Constraints"> |
| <meta name="resource-type" content="document"> |
| <meta name="distribution" content="global"> |
| <meta name="Generator" content="makeinfo"> |
| <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> |
| <link href="index.html#Top" rel="start" title="Top"> |
| <link href="Option-Index.html#Option-Index" rel="index" title="Option Index"> |
| <link href="index.html#SEC_Contents" rel="contents" title="Table of Contents"> |
| <link href="Constraints.html#Constraints" rel="up" title="Constraints"> |
| <link href="Multi_002dAlternative.html#Multi_002dAlternative" rel="next" title="Multi-Alternative"> |
| <link href="Constraints.html#Constraints" rel="prev" title="Constraints"> |
| <style type="text/css"> |
| <!-- |
| a.summary-letter {text-decoration: none} |
| blockquote.smallquotation {font-size: smaller} |
| div.display {margin-left: 3.2em} |
| div.example {margin-left: 3.2em} |
| div.indentedblock {margin-left: 3.2em} |
| div.lisp {margin-left: 3.2em} |
| div.smalldisplay {margin-left: 3.2em} |
| div.smallexample {margin-left: 3.2em} |
| div.smallindentedblock {margin-left: 3.2em; font-size: smaller} |
| div.smalllisp {margin-left: 3.2em} |
| kbd {font-style:oblique} |
| pre.display {font-family: inherit} |
| pre.format {font-family: inherit} |
| pre.menu-comment {font-family: serif} |
| pre.menu-preformatted {font-family: serif} |
| pre.smalldisplay {font-family: inherit; font-size: smaller} |
| pre.smallexample {font-size: smaller} |
| pre.smallformat {font-family: inherit; font-size: smaller} |
| pre.smalllisp {font-size: smaller} |
| span.nocodebreak {white-space:nowrap} |
| span.nolinebreak {white-space:nowrap} |
| span.roman {font-family:serif; font-weight:normal} |
| span.sansserif {font-family:sans-serif; font-weight:normal} |
| ul.no-bullet {list-style: none} |
| --> |
| </style> |
| |
| |
| </head> |
| |
| <body lang="en" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000"> |
| <a name="Simple-Constraints"></a> |
| <div class="header"> |
| <p> |
| Next: <a href="Multi_002dAlternative.html#Multi_002dAlternative" accesskey="n" rel="next">Multi-Alternative</a>, Up: <a href="Constraints.html#Constraints" accesskey="u" rel="up">Constraints</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html#Option-Index" title="Index" rel="index">Index</a>]</p> |
| </div> |
| <hr> |
| <a name="Simple-Constraints-1"></a> |
| <h4 class="subsection">16.8.1 Simple Constraints</h4> |
| <a name="index-simple-constraints"></a> |
| |
| <p>The simplest kind of constraint is a string full of letters, each of |
| which describes one kind of operand that is permitted. Here are |
| the letters that are allowed: |
| </p> |
| <dl compact="compact"> |
| <dt>whitespace</dt> |
| <dd><p>Whitespace characters are ignored and can be inserted at any position |
| except the first. This enables each alternative for different operands to |
| be visually aligned in the machine description even if they have different |
| number of constraints and modifiers. |
| </p> |
| <a name="index-m-in-constraint"></a> |
| <a name="index-memory-references-in-constraints"></a> |
| </dd> |
| <dt>‘<samp>m</samp>’</dt> |
| <dd><p>A memory operand is allowed, with any kind of address that the machine |
| supports in general. |
| Note that the letter used for the general memory constraint can be |
| re-defined by a back end using the <code>TARGET_MEM_CONSTRAINT</code> macro. |
| </p> |
| <a name="index-offsettable-address"></a> |
| <a name="index-o-in-constraint"></a> |
| </dd> |
| <dt>‘<samp>o</samp>’</dt> |
| <dd><p>A memory operand is allowed, but only if the address is |
| <em>offsettable</em>. This means that adding a small integer (actually, |
| the width in bytes of the operand, as determined by its machine mode) |
| may be added to the address and the result is also a valid memory |
| address. |
| </p> |
| <a name="index-autoincrement_002fdecrement-addressing"></a> |
| <p>For example, an address which is constant is offsettable; so is an |
| address that is the sum of a register and a constant (as long as a |
| slightly larger constant is also within the range of address-offsets |
| supported by the machine); but an autoincrement or autodecrement |
| address is not offsettable. More complicated indirect/indexed |
| addresses may or may not be offsettable depending on the other |
| addressing modes that the machine supports. |
| </p> |
| <p>Note that in an output operand which can be matched by another |
| operand, the constraint letter ‘<samp>o</samp>’ is valid only when accompanied |
| by both ‘<samp><</samp>’ (if the target machine has predecrement addressing) |
| and ‘<samp>></samp>’ (if the target machine has preincrement addressing). |
| </p> |
| <a name="index-V-in-constraint"></a> |
| </dd> |
| <dt>‘<samp>V</samp>’</dt> |
| <dd><p>A memory operand that is not offsettable. In other words, anything that |
| would fit the ‘<samp>m</samp>’ constraint but not the ‘<samp>o</samp>’ constraint. |
| </p> |
| <a name="index-_003c-in-constraint"></a> |
| </dd> |
| <dt>‘<samp><</samp>’</dt> |
| <dd><p>A memory operand with autodecrement addressing (either predecrement or |
| postdecrement) is allowed. In inline <code>asm</code> this constraint is only |
| allowed if the operand is used exactly once in an instruction that can |
| handle the side-effects. Not using an operand with ‘<samp><</samp>’ in constraint |
| string in the inline <code>asm</code> pattern at all or using it in multiple |
| instructions isn’t valid, because the side-effects wouldn’t be performed |
| or would be performed more than once. Furthermore, on some targets |
| the operand with ‘<samp><</samp>’ in constraint string must be accompanied by |
| special instruction suffixes like <code>%U0</code> instruction suffix on PowerPC |
| or <code>%P0</code> on IA-64. |
| </p> |
| <a name="index-_003e-in-constraint"></a> |
| </dd> |
| <dt>‘<samp>></samp>’</dt> |
| <dd><p>A memory operand with autoincrement addressing (either preincrement or |
| postincrement) is allowed. In inline <code>asm</code> the same restrictions |
| as for ‘<samp><</samp>’ apply. |
| </p> |
| <a name="index-r-in-constraint"></a> |
| <a name="index-registers-in-constraints"></a> |
| </dd> |
| <dt>‘<samp>r</samp>’</dt> |
| <dd><p>A register operand is allowed provided that it is in a general |
| register. |
| </p> |
| <a name="index-constants-in-constraints"></a> |
| <a name="index-i-in-constraint"></a> |
| </dd> |
| <dt>‘<samp>i</samp>’</dt> |
| <dd><p>An immediate integer operand (one with constant value) is allowed. |
| This includes symbolic constants whose values will be known only at |
| assembly time or later. |
| </p> |
| <a name="index-n-in-constraint"></a> |
| </dd> |
| <dt>‘<samp>n</samp>’</dt> |
| <dd><p>An immediate integer operand with a known numeric value is allowed. |
| Many systems cannot support assembly-time constants for operands less |
| than a word wide. Constraints for these operands should use ‘<samp>n</samp>’ |
| rather than ‘<samp>i</samp>’. |
| </p> |
| <a name="index-I-in-constraint"></a> |
| </dd> |
| <dt>‘<samp>I</samp>’, ‘<samp>J</samp>’, ‘<samp>K</samp>’, … ‘<samp>P</samp>’</dt> |
| <dd><p>Other letters in the range ‘<samp>I</samp>’ through ‘<samp>P</samp>’ may be defined in |
| a machine-dependent fashion to permit immediate integer operands with |
| explicit integer values in specified ranges. For example, on the |
| 68000, ‘<samp>I</samp>’ is defined to stand for the range of values 1 to 8. |
| This is the range permitted as a shift count in the shift |
| instructions. |
| </p> |
| <a name="index-E-in-constraint"></a> |
| </dd> |
| <dt>‘<samp>E</samp>’</dt> |
| <dd><p>An immediate floating operand (expression code <code>const_double</code>) is |
| allowed, but only if the target floating point format is the same as |
| that of the host machine (on which the compiler is running). |
| </p> |
| <a name="index-F-in-constraint"></a> |
| </dd> |
| <dt>‘<samp>F</samp>’</dt> |
| <dd><p>An immediate floating operand (expression code <code>const_double</code> or |
| <code>const_vector</code>) is allowed. |
| </p> |
| <a name="index-G-in-constraint"></a> |
| <a name="index-H-in-constraint"></a> |
| </dd> |
| <dt>‘<samp>G</samp>’, ‘<samp>H</samp>’</dt> |
| <dd><p>‘<samp>G</samp>’ and ‘<samp>H</samp>’ may be defined in a machine-dependent fashion to |
| permit immediate floating operands in particular ranges of values. |
| </p> |
| <a name="index-s-in-constraint"></a> |
| </dd> |
| <dt>‘<samp>s</samp>’</dt> |
| <dd><p>An immediate integer operand whose value is not an explicit integer is |
| allowed. |
| </p> |
| <p>This might appear strange; if an insn allows a constant operand with a |
| value not known at compile time, it certainly must allow any known |
| value. So why use ‘<samp>s</samp>’ instead of ‘<samp>i</samp>’? Sometimes it allows |
| better code to be generated. |
| </p> |
| <p>For example, on the 68000 in a fullword instruction it is possible to |
| use an immediate operand; but if the immediate value is between -128 |
| and 127, better code results from loading the value into a register and |
| using the register. This is because the load into the register can be |
| done with a ‘<samp>moveq</samp>’ instruction. We arrange for this to happen |
| by defining the letter ‘<samp>K</samp>’ to mean “any integer outside the |
| range -128 to 127”, and then specifying ‘<samp>Ks</samp>’ in the operand |
| constraints. |
| </p> |
| <a name="index-g-in-constraint"></a> |
| </dd> |
| <dt>‘<samp>g</samp>’</dt> |
| <dd><p>Any register, memory or immediate integer operand is allowed, except for |
| registers that are not general registers. |
| </p> |
| <a name="index-X-in-constraint"></a> |
| </dd> |
| <dt>‘<samp>X</samp>’</dt> |
| <dd><p>Any operand whatsoever is allowed, even if it does not satisfy |
| <code>general_operand</code>. This is normally used in the constraint of |
| a <code>match_scratch</code> when certain alternatives will not actually |
| require a scratch register. |
| </p> |
| <a name="index-0-in-constraint"></a> |
| <a name="index-digits-in-constraint"></a> |
| </dd> |
| <dt>‘<samp>0</samp>’, ‘<samp>1</samp>’, ‘<samp>2</samp>’, … ‘<samp>9</samp>’</dt> |
| <dd><p>An operand that matches the specified operand number is allowed. If a |
| digit is used together with letters within the same alternative, the |
| digit should come last. |
| </p> |
| <p>This number is allowed to be more than a single digit. If multiple |
| digits are encountered consecutively, they are interpreted as a single |
| decimal integer. There is scant chance for ambiguity, since to-date |
| it has never been desirable that ‘<samp>10</samp>’ be interpreted as matching |
| either operand 1 <em>or</em> operand 0. Should this be desired, one |
| can use multiple alternatives instead. |
| </p> |
| <a name="index-matching-constraint"></a> |
| <a name="index-constraint_002c-matching"></a> |
| <p>This is called a <em>matching constraint</em> and what it really means is |
| that the assembler has only a single operand that fills two roles |
| considered separate in the RTL insn. For example, an add insn has two |
| input operands and one output operand in the RTL, but on most CISC |
| machines an add instruction really has only two operands, one of them an |
| input-output operand: |
| </p> |
| <div class="smallexample"> |
| <pre class="smallexample">addl #35,r12 |
| </pre></div> |
| |
| <p>Matching constraints are used in these circumstances. |
| More precisely, the two operands that match must include one input-only |
| operand and one output-only operand. Moreover, the digit must be a |
| smaller number than the number of the operand that uses it in the |
| constraint. |
| </p> |
| <p>For operands to match in a particular case usually means that they |
| are identical-looking RTL expressions. But in a few special cases |
| specific kinds of dissimilarity are allowed. For example, <code>*x</code> |
| as an input operand will match <code>*x++</code> as an output operand. |
| For proper results in such cases, the output template should always |
| use the output-operand’s number when printing the operand. |
| </p> |
| <a name="index-load-address-instruction"></a> |
| <a name="index-push-address-instruction"></a> |
| <a name="index-address-constraints"></a> |
| <a name="index-p-in-constraint"></a> |
| </dd> |
| <dt>‘<samp>p</samp>’</dt> |
| <dd><p>An operand that is a valid memory address is allowed. This is |
| for “load address” and “push address” instructions. |
| </p> |
| <a name="index-address_005foperand-1"></a> |
| <p>‘<samp>p</samp>’ in the constraint must be accompanied by <code>address_operand</code> |
| as the predicate in the <code>match_operand</code>. This predicate interprets |
| the mode specified in the <code>match_operand</code> as the mode of the memory |
| reference for which the address would be valid. |
| </p> |
| <a name="index-other-register-constraints"></a> |
| <a name="index-extensible-constraints"></a> |
| </dd> |
| <dt><var>other-letters</var></dt> |
| <dd><p>Other letters can be defined in machine-dependent fashion to stand for |
| particular classes of registers or other arbitrary operand types. |
| ‘<samp>d</samp>’, ‘<samp>a</samp>’ and ‘<samp>f</samp>’ are defined on the 68000/68020 to stand |
| for data, address and floating point registers. |
| </p></dd> |
| </dl> |
| |
| <p>In order to have valid assembler code, each operand must satisfy |
| its constraint. But a failure to do so does not prevent the pattern |
| from applying to an insn. Instead, it directs the compiler to modify |
| the code so that the constraint will be satisfied. Usually this is |
| done by copying an operand into a register. |
| </p> |
| <p>Contrast, therefore, the two instruction patterns that follow: |
| </p> |
| <div class="smallexample"> |
| <pre class="smallexample">(define_insn "" |
| [(set (match_operand:SI 0 "general_operand" "=r") |
| (plus:SI (match_dup 0) |
| (match_operand:SI 1 "general_operand" "r")))] |
| "" |
| "…") |
| </pre></div> |
| |
| <p>which has two operands, one of which must appear in two places, and |
| </p> |
| <div class="smallexample"> |
| <pre class="smallexample">(define_insn "" |
| [(set (match_operand:SI 0 "general_operand" "=r") |
| (plus:SI (match_operand:SI 1 "general_operand" "0") |
| (match_operand:SI 2 "general_operand" "r")))] |
| "" |
| "…") |
| </pre></div> |
| |
| <p>which has three operands, two of which are required by a constraint to be |
| identical. If we are considering an insn of the form |
| </p> |
| <div class="smallexample"> |
| <pre class="smallexample">(insn <var>n</var> <var>prev</var> <var>next</var> |
| (set (reg:SI 3) |
| (plus:SI (reg:SI 6) (reg:SI 109))) |
| …) |
| </pre></div> |
| |
| <p>the first pattern would not apply at all, because this insn does not |
| contain two identical subexpressions in the right place. The pattern would |
| say, “That does not look like an add instruction; try other patterns”. |
| The second pattern would say, “Yes, that’s an add instruction, but there |
| is something wrong with it”. It would direct the reload pass of the |
| compiler to generate additional insns to make the constraint true. The |
| results might look like this: |
| </p> |
| <div class="smallexample"> |
| <pre class="smallexample">(insn <var>n2</var> <var>prev</var> <var>n</var> |
| (set (reg:SI 3) (reg:SI 6)) |
| …) |
| |
| (insn <var>n</var> <var>n2</var> <var>next</var> |
| (set (reg:SI 3) |
| (plus:SI (reg:SI 3) (reg:SI 109))) |
| …) |
| </pre></div> |
| |
| <p>It is up to you to make sure that each operand, in each pattern, has |
| constraints that can handle any RTL expression that could be present for |
| that operand. (When multiple alternatives are in use, each pattern must, |
| for each possible combination of operand expressions, have at least one |
| alternative which can handle that combination of operands.) The |
| constraints don’t need to <em>allow</em> any possible operand—when this is |
| the case, they do not constrain—but they must at least point the way to |
| reloading any possible operand so that it will fit. |
| </p> |
| <ul> |
| <li> If the constraint accepts whatever operands the predicate permits, |
| there is no problem: reloading is never necessary for this operand. |
| |
| <p>For example, an operand whose constraints permit everything except |
| registers is safe provided its predicate rejects registers. |
| </p> |
| <p>An operand whose predicate accepts only constant values is safe |
| provided its constraints include the letter ‘<samp>i</samp>’. If any possible |
| constant value is accepted, then nothing less than ‘<samp>i</samp>’ will do; |
| if the predicate is more selective, then the constraints may also be |
| more selective. |
| </p> |
| </li><li> Any operand expression can be reloaded by copying it into a register. |
| So if an operand’s constraints allow some kind of register, it is |
| certain to be safe. It need not permit all classes of registers; the |
| compiler knows how to copy a register into another register of the |
| proper class in order to make an instruction valid. |
| |
| </li><li> <a name="index-nonoffsettable-memory-reference"></a> |
| <a name="index-memory-reference_002c-nonoffsettable"></a> |
| A nonoffsettable memory reference can be reloaded by copying the |
| address into a register. So if the constraint uses the letter |
| ‘<samp>o</samp>’, all memory references are taken care of. |
| |
| </li><li> A constant operand can be reloaded by allocating space in memory to |
| hold it as preinitialized data. Then the memory reference can be used |
| in place of the constant. So if the constraint uses the letters |
| ‘<samp>o</samp>’ or ‘<samp>m</samp>’, constant operands are not a problem. |
| |
| </li><li> If the constraint permits a constant and a pseudo register used in an insn |
| was not allocated to a hard register and is equivalent to a constant, |
| the register will be replaced with the constant. If the predicate does |
| not permit a constant and the insn is re-recognized for some reason, the |
| compiler will crash. Thus the predicate must always recognize any |
| objects allowed by the constraint. |
| </li></ul> |
| |
| <p>If the operand’s predicate can recognize registers, but the constraint does |
| not permit them, it can make the compiler crash. When this operand happens |
| to be a register, the reload pass will be stymied, because it does not know |
| how to copy a register temporarily into memory. |
| </p> |
| <p>If the predicate accepts a unary operator, the constraint applies to the |
| operand. For example, the MIPS processor at ISA level 3 supports an |
| instruction which adds two registers in <code>SImode</code> to produce a |
| <code>DImode</code> result, but only if the registers are correctly sign |
| extended. This predicate for the input operands accepts a |
| <code>sign_extend</code> of an <code>SImode</code> register. Write the constraint |
| to indicate the type of register that is required for the operand of the |
| <code>sign_extend</code>. |
| </p> |
| <hr> |
| <div class="header"> |
| <p> |
| Next: <a href="Multi_002dAlternative.html#Multi_002dAlternative" accesskey="n" rel="next">Multi-Alternative</a>, Up: <a href="Constraints.html#Constraints" accesskey="u" rel="up">Constraints</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html#Option-Index" title="Index" rel="index">Index</a>]</p> |
| </div> |
| |
| |
| |
| </body> |
| </html> |
