You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
433 lines
20 KiB
HTML
433 lines
20 KiB
HTML
4 years ago
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||
|
|
<html>
|
||
|
|
<!-- Copyright (C) 1988-2018 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 6.4, http://www.gnu.org/software/texinfo/ -->
|
||
|
|
<head>
|
||
|
|
<title>Simple Constraints (GNU Compiler Collection (GCC) Internals)</title>
|
||
|
|
|
||
|
|
<meta name="description" content="Simple Constraints (GNU Compiler Collection (GCC) Internals)">
|
||
|
|
<meta name="keywords" content="Simple Constraints (GNU Compiler Collection (GCC) Internals)">
|
||
|
|
<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.indentedblock {margin-right: 0em}
|
||
|
|
blockquote.smallindentedblock {margin-right: 0em; font-size: smaller}
|
||
|
|
blockquote.smallquotation {font-size: smaller}
|
||
|
|
div.display {margin-left: 3.2em}
|
||
|
|
div.example {margin-left: 3.2em}
|
||
|
|
div.lisp {margin-left: 3.2em}
|
||
|
|
div.smalldisplay {margin-left: 3.2em}
|
||
|
|
div.smallexample {margin-left: 3.2em}
|
||
|
|
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.nolinebreak {white-space: nowrap}
|
||
|
|
span.roman {font-family: initial; font-weight: normal}
|
||
|
|
span.sansserif {font-family: sans-serif; font-weight: normal}
|
||
|
|
ul.no-bullet {list-style: none}
|
||
|
|
-->
|
||
|
|
</style>
|
||
|
|
|
||
|
|
|
||
|
|
</head>
|
||
|
|
|
||
|
|
<body lang="en">
|
||
|
|
<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">17.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>
|