| <!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: Costs</title> |
| |
| <meta name="description" content="GNU Compiler Collection (GCC) Internals: Costs"> |
| <meta name="keywords" content="GNU Compiler Collection (GCC) Internals: Costs"> |
| <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="Target-Macros.html#Target-Macros" rel="up" title="Target Macros"> |
| <link href="Scheduling.html#Scheduling" rel="next" title="Scheduling"> |
| <link href="MODE_005fCC-Condition-Codes.html#MODE_005fCC-Condition-Codes" rel="prev" title="MODE_CC Condition Codes"> |
| <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="Costs"></a> |
| <div class="header"> |
| <p> |
| Next: <a href="Scheduling.html#Scheduling" accesskey="n" rel="next">Scheduling</a>, Previous: <a href="Condition-Code.html#Condition-Code" accesskey="p" rel="prev">Condition Code</a>, Up: <a href="Target-Macros.html#Target-Macros" accesskey="u" rel="up">Target Macros</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="Describing-Relative-Costs-of-Operations"></a> |
| <h3 class="section">17.17 Describing Relative Costs of Operations</h3> |
| <a name="index-costs-of-instructions"></a> |
| <a name="index-relative-costs"></a> |
| <a name="index-speed-of-instructions"></a> |
| |
| <p>These macros let you describe the relative speed of various operations |
| on the target machine. |
| </p> |
| <dl> |
| <dt><a name="index-REGISTER_005fMOVE_005fCOST"></a>Macro: <strong>REGISTER_MOVE_COST</strong> <em>(<var>mode</var>, <var>from</var>, <var>to</var>)</em></dt> |
| <dd><p>A C expression for the cost of moving data of mode <var>mode</var> from a |
| register in class <var>from</var> to one in class <var>to</var>. The classes are |
| expressed using the enumeration values such as <code>GENERAL_REGS</code>. A |
| value of 2 is the default; other values are interpreted relative to |
| that. |
| </p> |
| <p>It is not required that the cost always equal 2 when <var>from</var> is the |
| same as <var>to</var>; on some machines it is expensive to move between |
| registers if they are not general registers. |
| </p> |
| <p>If reload sees an insn consisting of a single <code>set</code> between two |
| hard registers, and if <code>REGISTER_MOVE_COST</code> applied to their |
| classes returns a value of 2, reload does not check to ensure that the |
| constraints of the insn are met. Setting a cost of other than 2 will |
| allow reload to verify that the constraints are met. You should do this |
| if the ‘<samp>mov<var>m</var></samp>’ pattern’s constraints do not allow such copying. |
| </p> |
| <p>These macros are obsolete, new ports should use the target hook |
| <code>TARGET_REGISTER_MOVE_COST</code> instead. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><a name="index-TARGET_005fREGISTER_005fMOVE_005fCOST"></a>Target Hook: <em>int</em> <strong>TARGET_REGISTER_MOVE_COST</strong> <em>(enum machine_mode <var>mode</var>, reg_class_t <var>from</var>, reg_class_t <var>to</var>)</em></dt> |
| <dd><p>This target hook should return the cost of moving data of mode <var>mode</var> |
| from a register in class <var>from</var> to one in class <var>to</var>. The classes |
| are expressed using the enumeration values such as <code>GENERAL_REGS</code>. |
| A value of 2 is the default; other values are interpreted relative to |
| that. |
| </p> |
| <p>It is not required that the cost always equal 2 when <var>from</var> is the |
| same as <var>to</var>; on some machines it is expensive to move between |
| registers if they are not general registers. |
| </p> |
| <p>If reload sees an insn consisting of a single <code>set</code> between two |
| hard registers, and if <code>TARGET_REGISTER_MOVE_COST</code> applied to their |
| classes returns a value of 2, reload does not check to ensure that the |
| constraints of the insn are met. Setting a cost of other than 2 will |
| allow reload to verify that the constraints are met. You should do this |
| if the ‘<samp>mov<var>m</var></samp>’ pattern’s constraints do not allow such copying. |
| </p> |
| <p>The default version of this function returns 2. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><a name="index-MEMORY_005fMOVE_005fCOST"></a>Macro: <strong>MEMORY_MOVE_COST</strong> <em>(<var>mode</var>, <var>class</var>, <var>in</var>)</em></dt> |
| <dd><p>A C expression for the cost of moving data of mode <var>mode</var> between a |
| register of class <var>class</var> and memory; <var>in</var> is zero if the value |
| is to be written to memory, nonzero if it is to be read in. This cost |
| is relative to those in <code>REGISTER_MOVE_COST</code>. If moving between |
| registers and memory is more expensive than between two registers, you |
| should define this macro to express the relative cost. |
| </p> |
| <p>If you do not define this macro, GCC uses a default cost of 4 plus |
| the cost of copying via a secondary reload register, if one is |
| needed. If your machine requires a secondary reload register to copy |
| between memory and a register of <var>class</var> but the reload mechanism is |
| more complex than copying via an intermediate, define this macro to |
| reflect the actual cost of the move. |
| </p> |
| <p>GCC defines the function <code>memory_move_secondary_cost</code> if |
| secondary reloads are needed. It computes the costs due to copying via |
| a secondary register. If your machine copies from memory using a |
| secondary register in the conventional way but the default base value of |
| 4 is not correct for your machine, define this macro to add some other |
| value to the result of that function. The arguments to that function |
| are the same as to this macro. |
| </p> |
| <p>These macros are obsolete, new ports should use the target hook |
| <code>TARGET_MEMORY_MOVE_COST</code> instead. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><a name="index-TARGET_005fMEMORY_005fMOVE_005fCOST"></a>Target Hook: <em>int</em> <strong>TARGET_MEMORY_MOVE_COST</strong> <em>(enum machine_mode <var>mode</var>, reg_class_t <var>rclass</var>, bool <var>in</var>)</em></dt> |
| <dd><p>This target hook should return the cost of moving data of mode <var>mode</var> |
| between a register of class <var>rclass</var> and memory; <var>in</var> is <code>false</code> |
| if the value is to be written to memory, <code>true</code> if it is to be read in. |
| This cost is relative to those in <code>TARGET_REGISTER_MOVE_COST</code>. |
| If moving between registers and memory is more expensive than between two |
| registers, you should add this target hook to express the relative cost. |
| </p> |
| <p>If you do not add this target hook, GCC uses a default cost of 4 plus |
| the cost of copying via a secondary reload register, if one is |
| needed. If your machine requires a secondary reload register to copy |
| between memory and a register of <var>rclass</var> but the reload mechanism is |
| more complex than copying via an intermediate, use this target hook to |
| reflect the actual cost of the move. |
| </p> |
| <p>GCC defines the function <code>memory_move_secondary_cost</code> if |
| secondary reloads are needed. It computes the costs due to copying via |
| a secondary register. If your machine copies from memory using a |
| secondary register in the conventional way but the default base value of |
| 4 is not correct for your machine, use this target hook to add some other |
| value to the result of that function. The arguments to that function |
| are the same as to this target hook. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><a name="index-BRANCH_005fCOST"></a>Macro: <strong>BRANCH_COST</strong> <em>(<var>speed_p</var>, <var>predictable_p</var>)</em></dt> |
| <dd><p>A C expression for the cost of a branch instruction. A value of 1 is |
| the default; other values are interpreted relative to that. Parameter |
| <var>speed_p</var> is true when the branch in question should be optimized |
| for speed. When it is false, <code>BRANCH_COST</code> should return a value |
| optimal for code size rather than performance. <var>predictable_p</var> is |
| true for well-predicted branches. On many architectures the |
| <code>BRANCH_COST</code> can be reduced then. |
| </p></dd></dl> |
| |
| <p>Here are additional macros which do not specify precise relative costs, |
| but only that certain actions are more expensive than GCC would |
| ordinarily expect. |
| </p> |
| <dl> |
| <dt><a name="index-SLOW_005fBYTE_005fACCESS"></a>Macro: <strong>SLOW_BYTE_ACCESS</strong></dt> |
| <dd><p>Define this macro as a C expression which is nonzero if accessing less |
| than a word of memory (i.e. a <code>char</code> or a <code>short</code>) is no |
| faster than accessing a word of memory, i.e., if such access |
| require more than one instruction or if there is no difference in cost |
| between byte and (aligned) word loads. |
| </p> |
| <p>When this macro is not defined, the compiler will access a field by |
| finding the smallest containing object; when it is defined, a fullword |
| load will be used if alignment permits. Unless bytes accesses are |
| faster than word accesses, using word accesses is preferable since it |
| may eliminate subsequent memory access if subsequent accesses occur to |
| other fields in the same word of the structure, but to different bytes. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><a name="index-SLOW_005fUNALIGNED_005fACCESS"></a>Macro: <strong>SLOW_UNALIGNED_ACCESS</strong> <em>(<var>mode</var>, <var>alignment</var>)</em></dt> |
| <dd><p>Define this macro to be the value 1 if memory accesses described by the |
| <var>mode</var> and <var>alignment</var> parameters have a cost many times greater |
| than aligned accesses, for example if they are emulated in a trap |
| handler. |
| </p> |
| <p>When this macro is nonzero, the compiler will act as if |
| <code>STRICT_ALIGNMENT</code> were nonzero when generating code for block |
| moves. This can cause significantly more instructions to be produced. |
| Therefore, do not set this macro nonzero if unaligned accesses only add a |
| cycle or two to the time for a memory access. |
| </p> |
| <p>If the value of this macro is always zero, it need not be defined. If |
| this macro is defined, it should produce a nonzero value when |
| <code>STRICT_ALIGNMENT</code> is nonzero. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><a name="index-MOVE_005fRATIO"></a>Macro: <strong>MOVE_RATIO</strong> <em>(<var>speed</var>)</em></dt> |
| <dd><p>The threshold of number of scalar memory-to-memory move insns, <em>below</em> |
| which a sequence of insns should be generated instead of a |
| string move insn or a library call. Increasing the value will always |
| make code faster, but eventually incurs high cost in increased code size. |
| </p> |
| <p>Note that on machines where the corresponding move insn is a |
| <code>define_expand</code> that emits a sequence of insns, this macro counts |
| the number of such sequences. |
| </p> |
| <p>The parameter <var>speed</var> is true if the code is currently being |
| optimized for speed rather than size. |
| </p> |
| <p>If you don’t define this, a reasonable default is used. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><a name="index-TARGET_005fUSE_005fBY_005fPIECES_005fINFRASTRUCTURE_005fP"></a>Target Hook: <em>bool</em> <strong>TARGET_USE_BY_PIECES_INFRASTRUCTURE_P</strong> <em>(unsigned HOST_WIDE_INT <var>size</var>, unsigned int <var>alignment</var>, enum by_pieces_operation <var>op</var>, bool <var>speed_p</var>)</em></dt> |
| <dd><p>GCC will attempt several strategies when asked to copy between |
| two areas of memory, or to set, clear or store to memory, for example |
| when copying a <code>struct</code>. The <code>by_pieces</code> infrastructure |
| implements such memory operations as a sequence of load, store or move |
| insns. Alternate strategies are to expand the |
| <code>movmem</code> or <code>setmem</code> optabs, to emit a library call, or to emit |
| unit-by-unit, loop-based operations. |
| </p> |
| <p>This target hook should return true if, for a memory operation with a |
| given <var>size</var> and <var>alignment</var>, using the <code>by_pieces</code> |
| infrastructure is expected to result in better code generation. |
| Both <var>size</var> and <var>alignment</var> are measured in terms of storage |
| units. |
| </p> |
| <p>The parameter <var>op</var> is one of: <code>CLEAR_BY_PIECES</code>, |
| <code>MOVE_BY_PIECES</code>, <code>SET_BY_PIECES</code>, <code>STORE_BY_PIECES</code>. |
| These describe the type of memory operation under consideration. |
| </p> |
| <p>The parameter <var>speed_p</var> is true if the code is currently being |
| optimized for speed rather than size. |
| </p> |
| <p>Returning true for higher values of <var>size</var> can improve code generation |
| for speed if the target does not provide an implementation of the |
| <code>movmem</code> or <code>setmem</code> standard names, if the <code>movmem</code> or |
| <code>setmem</code> implementation would be more expensive than a sequence of |
| insns, or if the overhead of a library call would dominate that of |
| the body of the memory operation. |
| </p> |
| <p>Returning true for higher values of <code>size</code> may also cause an increase |
| in code size, for example where the number of insns emitted to perform a |
| move would be greater than that of a library call. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><a name="index-MOVE_005fMAX_005fPIECES"></a>Macro: <strong>MOVE_MAX_PIECES</strong></dt> |
| <dd><p>A C expression used by <code>move_by_pieces</code> to determine the largest unit |
| a load or store used to copy memory is. Defaults to <code>MOVE_MAX</code>. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><a name="index-CLEAR_005fRATIO"></a>Macro: <strong>CLEAR_RATIO</strong> <em>(<var>speed</var>)</em></dt> |
| <dd><p>The threshold of number of scalar move insns, <em>below</em> which a sequence |
| of insns should be generated to clear memory instead of a string clear insn |
| or a library call. Increasing the value will always make code faster, but |
| eventually incurs high cost in increased code size. |
| </p> |
| <p>The parameter <var>speed</var> is true if the code is currently being |
| optimized for speed rather than size. |
| </p> |
| <p>If you don’t define this, a reasonable default is used. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><a name="index-SET_005fRATIO"></a>Macro: <strong>SET_RATIO</strong> <em>(<var>speed</var>)</em></dt> |
| <dd><p>The threshold of number of scalar move insns, <em>below</em> which a sequence |
| of insns should be generated to set memory to a constant value, instead of |
| a block set insn or a library call. |
| Increasing the value will always make code faster, but |
| eventually incurs high cost in increased code size. |
| </p> |
| <p>The parameter <var>speed</var> is true if the code is currently being |
| optimized for speed rather than size. |
| </p> |
| <p>If you don’t define this, it defaults to the value of <code>MOVE_RATIO</code>. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><a name="index-USE_005fLOAD_005fPOST_005fINCREMENT"></a>Macro: <strong>USE_LOAD_POST_INCREMENT</strong> <em>(<var>mode</var>)</em></dt> |
| <dd><p>A C expression used to determine whether a load postincrement is a good |
| thing to use for a given mode. Defaults to the value of |
| <code>HAVE_POST_INCREMENT</code>. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><a name="index-USE_005fLOAD_005fPOST_005fDECREMENT"></a>Macro: <strong>USE_LOAD_POST_DECREMENT</strong> <em>(<var>mode</var>)</em></dt> |
| <dd><p>A C expression used to determine whether a load postdecrement is a good |
| thing to use for a given mode. Defaults to the value of |
| <code>HAVE_POST_DECREMENT</code>. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><a name="index-USE_005fLOAD_005fPRE_005fINCREMENT"></a>Macro: <strong>USE_LOAD_PRE_INCREMENT</strong> <em>(<var>mode</var>)</em></dt> |
| <dd><p>A C expression used to determine whether a load preincrement is a good |
| thing to use for a given mode. Defaults to the value of |
| <code>HAVE_PRE_INCREMENT</code>. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><a name="index-USE_005fLOAD_005fPRE_005fDECREMENT"></a>Macro: <strong>USE_LOAD_PRE_DECREMENT</strong> <em>(<var>mode</var>)</em></dt> |
| <dd><p>A C expression used to determine whether a load predecrement is a good |
| thing to use for a given mode. Defaults to the value of |
| <code>HAVE_PRE_DECREMENT</code>. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><a name="index-USE_005fSTORE_005fPOST_005fINCREMENT"></a>Macro: <strong>USE_STORE_POST_INCREMENT</strong> <em>(<var>mode</var>)</em></dt> |
| <dd><p>A C expression used to determine whether a store postincrement is a good |
| thing to use for a given mode. Defaults to the value of |
| <code>HAVE_POST_INCREMENT</code>. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><a name="index-USE_005fSTORE_005fPOST_005fDECREMENT"></a>Macro: <strong>USE_STORE_POST_DECREMENT</strong> <em>(<var>mode</var>)</em></dt> |
| <dd><p>A C expression used to determine whether a store postdecrement is a good |
| thing to use for a given mode. Defaults to the value of |
| <code>HAVE_POST_DECREMENT</code>. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><a name="index-USE_005fSTORE_005fPRE_005fINCREMENT"></a>Macro: <strong>USE_STORE_PRE_INCREMENT</strong> <em>(<var>mode</var>)</em></dt> |
| <dd><p>This macro is used to determine whether a store preincrement is a good |
| thing to use for a given mode. Defaults to the value of |
| <code>HAVE_PRE_INCREMENT</code>. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><a name="index-USE_005fSTORE_005fPRE_005fDECREMENT"></a>Macro: <strong>USE_STORE_PRE_DECREMENT</strong> <em>(<var>mode</var>)</em></dt> |
| <dd><p>This macro is used to determine whether a store predecrement is a good |
| thing to use for a given mode. Defaults to the value of |
| <code>HAVE_PRE_DECREMENT</code>. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><a name="index-NO_005fFUNCTION_005fCSE"></a>Macro: <strong>NO_FUNCTION_CSE</strong></dt> |
| <dd><p>Define this macro if it is as good or better to call a constant |
| function address than to call an address kept in a register. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><a name="index-LOGICAL_005fOP_005fNON_005fSHORT_005fCIRCUIT"></a>Macro: <strong>LOGICAL_OP_NON_SHORT_CIRCUIT</strong></dt> |
| <dd><p>Define this macro if a non-short-circuit operation produced by |
| ‘<samp>fold_range_test ()</samp>’ is optimal. This macro defaults to true if |
| <code>BRANCH_COST</code> is greater than or equal to the value 2. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><a name="index-TARGET_005fRTX_005fCOSTS"></a>Target Hook: <em>bool</em> <strong>TARGET_RTX_COSTS</strong> <em>(rtx <var>x</var>, int <var>code</var>, int <var>outer_code</var>, int <var>opno</var>, int *<var>total</var>, bool <var>speed</var>)</em></dt> |
| <dd><p>This target hook describes the relative costs of RTL expressions. |
| </p> |
| <p>The cost may depend on the precise form of the expression, which is |
| available for examination in <var>x</var>, and the fact that <var>x</var> appears |
| as operand <var>opno</var> of an expression with rtx code <var>outer_code</var>. |
| That is, the hook can assume that there is some rtx <var>y</var> such |
| that ‘<samp>GET_CODE (<var>y</var>) == <var>outer_code</var></samp>’ and such that |
| either (a) ‘<samp>XEXP (<var>y</var>, <var>opno</var>) == <var>x</var></samp>’ or |
| (b) ‘<samp>XVEC (<var>y</var>, <var>opno</var>)</samp>’ contains <var>x</var>. |
| </p> |
| <p><var>code</var> is <var>x</var>’s expression code—redundant, since it can be |
| obtained with <code>GET_CODE (<var>x</var>)</code>. |
| </p> |
| <p>In implementing this hook, you can use the construct |
| <code>COSTS_N_INSNS (<var>n</var>)</code> to specify a cost equal to <var>n</var> fast |
| instructions. |
| </p> |
| <p>On entry to the hook, <code>*<var>total</var></code> contains a default estimate |
| for the cost of the expression. The hook should modify this value as |
| necessary. Traditionally, the default costs are <code>COSTS_N_INSNS (5)</code> |
| for multiplications, <code>COSTS_N_INSNS (7)</code> for division and modulus |
| operations, and <code>COSTS_N_INSNS (1)</code> for all other operations. |
| </p> |
| <p>When optimizing for code size, i.e. when <code>speed</code> is |
| false, this target hook should be used to estimate the relative |
| size cost of an expression, again relative to <code>COSTS_N_INSNS</code>. |
| </p> |
| <p>The hook returns true when all subexpressions of <var>x</var> have been |
| processed, and false when <code>rtx_cost</code> should recurse. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><a name="index-TARGET_005fADDRESS_005fCOST"></a>Target Hook: <em>int</em> <strong>TARGET_ADDRESS_COST</strong> <em>(rtx <var>address</var>, enum machine_mode <var>mode</var>, addr_space_t <var>as</var>, bool <var>speed</var>)</em></dt> |
| <dd><p>This hook computes the cost of an addressing mode that contains |
| <var>address</var>. If not defined, the cost is computed from |
| the <var>address</var> expression and the <code>TARGET_RTX_COST</code> hook. |
| </p> |
| <p>For most CISC machines, the default cost is a good approximation of the |
| true cost of the addressing mode. However, on RISC machines, all |
| instructions normally have the same length and execution time. Hence |
| all addresses will have equal costs. |
| </p> |
| <p>In cases where more than one form of an address is known, the form with |
| the lowest cost will be used. If multiple forms have the same, lowest, |
| cost, the one that is the most complex will be used. |
| </p> |
| <p>For example, suppose an address that is equal to the sum of a register |
| and a constant is used twice in the same basic block. When this macro |
| is not defined, the address will be computed in a register and memory |
| references will be indirect through that register. On machines where |
| the cost of the addressing mode containing the sum is no higher than |
| that of a simple indirect reference, this will produce an additional |
| instruction and possibly require an additional register. Proper |
| specification of this macro eliminates this overhead for such machines. |
| </p> |
| <p>This hook is never called with an invalid address. |
| </p> |
| <p>On machines where an address involving more than one register is as |
| cheap as an address computation involving only one register, defining |
| <code>TARGET_ADDRESS_COST</code> to reflect this can cause two registers to |
| be live over a region of code where only one would have been if |
| <code>TARGET_ADDRESS_COST</code> were not defined in that manner. This effect |
| should be considered in the definition of this macro. Equivalent costs |
| should probably only be given to addresses with different numbers of |
| registers on machines with lots of registers. |
| </p></dd></dl> |
| |
| <hr> |
| <div class="header"> |
| <p> |
| Next: <a href="Scheduling.html#Scheduling" accesskey="n" rel="next">Scheduling</a>, Previous: <a href="Condition-Code.html#Condition-Code" accesskey="p" rel="prev">Condition Code</a>, Up: <a href="Target-Macros.html#Target-Macros" accesskey="u" rel="up">Target Macros</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> |
