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.
210 lines
9.4 KiB
HTML
210 lines
9.4 KiB
HTML
4 years ago
|
<html lang="en">
|
||
|
|
<head>
|
||
|
|
<title>define_peephole - GNU Compiler Collection (GCC) Internals</title>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html">
|
||
|
|
<meta name="description" content="GNU Compiler Collection (GCC) Internals">
|
||
|
|
<meta name="generator" content="makeinfo 4.13">
|
||
|
|
<link title="Top" rel="start" href="index.html#Top">
|
||
|
|
<link rel="up" href="Peephole-Definitions.html#Peephole-Definitions" title="Peephole Definitions">
|
||
|
|
<link rel="next" href="define_005fpeephole2.html#define_005fpeephole2" title="define_peephole2">
|
||
|
|
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||
|
|
<!--
|
||
|
|
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.-->
|
||
|
|
<meta http-equiv="Content-Style-Type" content="text/css">
|
||
|
|
<style type="text/css"><!--
|
||
|
|
pre.display { font-family:inherit }
|
||
|
|
pre.format { font-family:inherit }
|
||
|
|
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||
|
|
pre.smallformat { font-family:inherit; font-size:smaller }
|
||
|
|
pre.smallexample { font-size:smaller }
|
||
|
|
pre.smalllisp { font-size:smaller }
|
||
|
|
span.sc { font-variant:small-caps }
|
||
|
|
span.roman { font-family:serif; font-weight:normal; }
|
||
|
|
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||
|
|
--></style>
|
||
|
|
</head>
|
||
|
|
<body>
|
||
|
|
<div class="node">
|
||
|
|
<a name="define_peephole"></a>
|
||
|
|
<a name="define_005fpeephole"></a>
|
||
|
|
<p>
|
||
|
|
Next: <a rel="next" accesskey="n" href="define_005fpeephole2.html#define_005fpeephole2">define_peephole2</a>,
|
||
|
|
Up: <a rel="up" accesskey="u" href="Peephole-Definitions.html#Peephole-Definitions">Peephole Definitions</a>
|
||
|
|
<hr>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<h4 class="subsection">16.18.1 RTL to Text Peephole Optimizers</h4>
|
||
|
|
|
||
|
|
<p><a name="index-define_005fpeephole-3713"></a>
|
||
|
|
A definition looks like this:
|
||
|
|
|
||
|
|
<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>
|
||
|
|
<p class="noindent">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>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>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>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>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>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>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>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-3714"></a>The way to refer to the operands in <var>condition</var> is to write
|
||
|
|
<code>operands[</code><var>i</var><code>]</code> for operand number <var>i</var> (as matched by
|
||
|
|
<code>(match_operand </code><var>i</var><code> ...)</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-3715"></a>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 (</code><var>insn</var><code>,
|
||
|
|
</code><var>op</var><code>)</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[</code><var>i</var><code>]</code>).
|
||
|
|
|
||
|
|
<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>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>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>Here is an example, taken from the 68000 machine description:
|
||
|
|
|
||
|
|
<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>
|
||
|
|
<p>The effect of this optimization is to change
|
||
|
|
|
||
|
|
<pre class="smallexample"> jbsr _foobar
|
||
|
|
addql #4,sp
|
||
|
|
movel d1,sp@-
|
||
|
|
movel d0,sp@-
|
||
|
|
fmoved sp@+,fp0
|
||
|
|
</pre>
|
||
|
|
<p class="noindent">into
|
||
|
|
|
||
|
|
<pre class="smallexample"> jbsr _foobar
|
||
|
|
movel d1,sp@
|
||
|
|
movel d0,sp@-
|
||
|
|
fmoved sp@+,fp0
|
||
|
|
</pre>
|
||
|
|
<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,
|
||
|
|
|
||
|
|
<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>
|
||
|
|
<p class="noindent">then the way to mention this insn in a peephole is as follows:
|
||
|
|
|
||
|
|
<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>
|
||
|
|
</body></html>
|
||
|
|
|