| <!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: define_peephole</title> |
| |
| <meta name="description" content="GNU Compiler Collection (GCC) Internals: define_peephole"> |
| <meta name="keywords" content="GNU Compiler Collection (GCC) Internals: define_peephole"> |
| <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.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="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">16.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> |
