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.
256 lines
11 KiB
HTML
256 lines
11 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>define_peephole (GNU Compiler Collection (GCC) Internals)</title>
|
||
|
|
|
||
|
|
<meta name="description" content="define_peephole (GNU Compiler Collection (GCC) Internals)">
|
||
|
|
<meta name="keywords" content="define_peephole (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="Peephole-Definitions.html#Peephole-Definitions" rel="up" title="Peephole Definitions">
|
||
|
|
<link href="define_005fpeephole2.html#define_005fpeephole2" rel="next" title="define_peephole2">
|
||
|
|
<link href="Peephole-Definitions.html#Peephole-Definitions" rel="prev" title="Peephole Definitions">
|
||
|
|
<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="define_005fpeephole"></a>
|
||
|
|
<div class="header">
|
||
|
|
<p>
|
||
|
|
Next: <a href="define_005fpeephole2.html#define_005fpeephole2" accesskey="n" rel="next">define_peephole2</a>, Up: <a href="Peephole-Definitions.html#Peephole-Definitions" accesskey="u" rel="up">Peephole Definitions</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="RTL-to-Text-Peephole-Optimizers"></a>
|
||
|
|
<h4 class="subsection">17.18.1 RTL to Text Peephole Optimizers</h4>
|
||
|
|
<a name="index-define_005fpeephole"></a>
|
||
|
|
|
||
|
|
<p>A definition looks like this:
|
||
|
|
</p>
|
||
|
|
<div class="smallexample">
|
||
|
|
<pre class="smallexample">(define_peephole
|
||
|
|
[<var>insn-pattern-1</var>
|
||
|
|
<var>insn-pattern-2</var>
|
||
|
|
…]
|
||
|
|
"<var>condition</var>"
|
||
|
|
"<var>template</var>"
|
||
|
|
"<var>optional-insn-attributes</var>")
|
||
|
|
</pre></div>
|
||
|
|
|
||
|
|
<p>The last string operand may be omitted if you are not using any
|
||
|
|
machine-specific information in this machine description. If present,
|
||
|
|
it must obey the same rules as in a <code>define_insn</code>.
|
||
|
|
</p>
|
||
|
|
<p>In this skeleton, <var>insn-pattern-1</var> and so on are patterns to match
|
||
|
|
consecutive insns. The optimization applies to a sequence of insns when
|
||
|
|
<var>insn-pattern-1</var> matches the first one, <var>insn-pattern-2</var> matches
|
||
|
|
the next, and so on.
|
||
|
|
</p>
|
||
|
|
<p>Each of the insns matched by a peephole must also match a
|
||
|
|
<code>define_insn</code>. Peepholes are checked only at the last stage just
|
||
|
|
before code generation, and only optionally. Therefore, any insn which
|
||
|
|
would match a peephole but no <code>define_insn</code> will cause a crash in code
|
||
|
|
generation in an unoptimized compilation, or at various optimization
|
||
|
|
stages.
|
||
|
|
</p>
|
||
|
|
<p>The operands of the insns are matched with <code>match_operands</code>,
|
||
|
|
<code>match_operator</code>, and <code>match_dup</code>, as usual. What is not
|
||
|
|
usual is that the operand numbers apply to all the insn patterns in the
|
||
|
|
definition. So, you can check for identical operands in two insns by
|
||
|
|
using <code>match_operand</code> in one insn and <code>match_dup</code> in the
|
||
|
|
other.
|
||
|
|
</p>
|
||
|
|
<p>The operand constraints used in <code>match_operand</code> patterns do not have
|
||
|
|
any direct effect on the applicability of the peephole, but they will
|
||
|
|
be validated afterward, so make sure your constraints are general enough
|
||
|
|
to apply whenever the peephole matches. If the peephole matches
|
||
|
|
but the constraints are not satisfied, the compiler will crash.
|
||
|
|
</p>
|
||
|
|
<p>It is safe to omit constraints in all the operands of the peephole; or
|
||
|
|
you can write constraints which serve as a double-check on the criteria
|
||
|
|
previously tested.
|
||
|
|
</p>
|
||
|
|
<p>Once a sequence of insns matches the patterns, the <var>condition</var> is
|
||
|
|
checked. This is a C expression which makes the final decision whether to
|
||
|
|
perform the optimization (we do so if the expression is nonzero). If
|
||
|
|
<var>condition</var> is omitted (in other words, the string is empty) then the
|
||
|
|
optimization is applied to every sequence of insns that matches the
|
||
|
|
patterns.
|
||
|
|
</p>
|
||
|
|
<p>The defined peephole optimizations are applied after register allocation
|
||
|
|
is complete. Therefore, the peephole definition can check which
|
||
|
|
operands have ended up in which kinds of registers, just by looking at
|
||
|
|
the operands.
|
||
|
|
</p>
|
||
|
|
<a name="index-prev_005factive_005finsn"></a>
|
||
|
|
<p>The way to refer to the operands in <var>condition</var> is to write
|
||
|
|
<code>operands[<var>i</var>]</code> for operand number <var>i</var> (as matched by
|
||
|
|
<code>(match_operand <var>i</var> …)</code>). Use the variable <code>insn</code>
|
||
|
|
to refer to the last of the insns being matched; use
|
||
|
|
<code>prev_active_insn</code> to find the preceding insns.
|
||
|
|
</p>
|
||
|
|
<a name="index-dead_005for_005fset_005fp"></a>
|
||
|
|
<p>When optimizing computations with intermediate results, you can use
|
||
|
|
<var>condition</var> to match only when the intermediate results are not used
|
||
|
|
elsewhere. Use the C expression <code>dead_or_set_p (<var>insn</var>,
|
||
|
|
<var>op</var>)</code>, where <var>insn</var> is the insn in which you expect the value
|
||
|
|
to be used for the last time (from the value of <code>insn</code>, together
|
||
|
|
with use of <code>prev_nonnote_insn</code>), and <var>op</var> is the intermediate
|
||
|
|
value (from <code>operands[<var>i</var>]</code>).
|
||
|
|
</p>
|
||
|
|
<p>Applying the optimization means replacing the sequence of insns with one
|
||
|
|
new insn. The <var>template</var> controls ultimate output of assembler code
|
||
|
|
for this combined insn. It works exactly like the template of a
|
||
|
|
<code>define_insn</code>. Operand numbers in this template are the same ones
|
||
|
|
used in matching the original sequence of insns.
|
||
|
|
</p>
|
||
|
|
<p>The result of a defined peephole optimizer does not need to match any of
|
||
|
|
the insn patterns in the machine description; it does not even have an
|
||
|
|
opportunity to match them. The peephole optimizer definition itself serves
|
||
|
|
as the insn pattern to control how the insn is output.
|
||
|
|
</p>
|
||
|
|
<p>Defined peephole optimizers are run as assembler code is being output,
|
||
|
|
so the insns they produce are never combined or rearranged in any way.
|
||
|
|
</p>
|
||
|
|
<p>Here is an example, taken from the 68000 machine description:
|
||
|
|
</p>
|
||
|
|
<div class="smallexample">
|
||
|
|
<pre class="smallexample">(define_peephole
|
||
|
|
[(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4)))
|
||
|
|
(set (match_operand:DF 0 "register_operand" "=f")
|
||
|
|
(match_operand:DF 1 "register_operand" "ad"))]
|
||
|
|
"FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])"
|
||
|
|
{
|
||
|
|
rtx xoperands[2];
|
||
|
|
xoperands[1] = gen_rtx_REG (SImode, REGNO (operands[1]) + 1);
|
||
|
|
#ifdef MOTOROLA
|
||
|
|
output_asm_insn ("move.l %1,(sp)", xoperands);
|
||
|
|
output_asm_insn ("move.l %1,-(sp)", operands);
|
||
|
|
return "fmove.d (sp)+,%0";
|
||
|
|
#else
|
||
|
|
output_asm_insn ("movel %1,sp@", xoperands);
|
||
|
|
output_asm_insn ("movel %1,sp@-", operands);
|
||
|
|
return "fmoved sp@+,%0";
|
||
|
|
#endif
|
||
|
|
})
|
||
|
|
</pre></div>
|
||
|
|
|
||
|
|
<p>The effect of this optimization is to change
|
||
|
|
</p>
|
||
|
|
<div class="smallexample">
|
||
|
|
<pre class="smallexample">jbsr _foobar
|
||
|
|
addql #4,sp
|
||
|
|
movel d1,sp@-
|
||
|
|
movel d0,sp@-
|
||
|
|
fmoved sp@+,fp0
|
||
|
|
</pre></div>
|
||
|
|
|
||
|
|
<p>into
|
||
|
|
</p>
|
||
|
|
<div class="smallexample">
|
||
|
|
<pre class="smallexample">jbsr _foobar
|
||
|
|
movel d1,sp@
|
||
|
|
movel d0,sp@-
|
||
|
|
fmoved sp@+,fp0
|
||
|
|
</pre></div>
|
||
|
|
|
||
|
|
|
||
|
|
<p><var>insn-pattern-1</var> and so on look <em>almost</em> like the second
|
||
|
|
operand of <code>define_insn</code>. There is one important difference: the
|
||
|
|
second operand of <code>define_insn</code> consists of one or more RTX’s
|
||
|
|
enclosed in square brackets. Usually, there is only one: then the same
|
||
|
|
action can be written as an element of a <code>define_peephole</code>. But
|
||
|
|
when there are multiple actions in a <code>define_insn</code>, they are
|
||
|
|
implicitly enclosed in a <code>parallel</code>. Then you must explicitly
|
||
|
|
write the <code>parallel</code>, and the square brackets within it, in the
|
||
|
|
<code>define_peephole</code>. Thus, if an insn pattern looks like this,
|
||
|
|
</p>
|
||
|
|
<div class="smallexample">
|
||
|
|
<pre class="smallexample">(define_insn "divmodsi4"
|
||
|
|
[(set (match_operand:SI 0 "general_operand" "=d")
|
||
|
|
(div:SI (match_operand:SI 1 "general_operand" "0")
|
||
|
|
(match_operand:SI 2 "general_operand" "dmsK")))
|
||
|
|
(set (match_operand:SI 3 "general_operand" "=d")
|
||
|
|
(mod:SI (match_dup 1) (match_dup 2)))]
|
||
|
|
"TARGET_68020"
|
||
|
|
"divsl%.l %2,%3:%0")
|
||
|
|
</pre></div>
|
||
|
|
|
||
|
|
<p>then the way to mention this insn in a peephole is as follows:
|
||
|
|
</p>
|
||
|
|
<div class="smallexample">
|
||
|
|
<pre class="smallexample">(define_peephole
|
||
|
|
[…
|
||
|
|
(parallel
|
||
|
|
[(set (match_operand:SI 0 "general_operand" "=d")
|
||
|
|
(div:SI (match_operand:SI 1 "general_operand" "0")
|
||
|
|
(match_operand:SI 2 "general_operand" "dmsK")))
|
||
|
|
(set (match_operand:SI 3 "general_operand" "=d")
|
||
|
|
(mod:SI (match_dup 1) (match_dup 2)))])
|
||
|
|
…]
|
||
|
|
…)
|
||
|
|
</pre></div>
|
||
|
|
|
||
|
|
<hr>
|
||
|
|
<div class="header">
|
||
|
|
<p>
|
||
|
|
Next: <a href="define_005fpeephole2.html#define_005fpeephole2" accesskey="n" rel="next">define_peephole2</a>, Up: <a href="Peephole-Definitions.html#Peephole-Definitions" accesskey="u" rel="up">Peephole Definitions</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>
|