| Message ID | b043f49b7c81c4d92f4e36807f28c49781fe63f3.1507574244.git.segher@kernel.crashing.org |
|---|---|
| State | New |
| Headers | show |
| Series | [1/3] Replace insn_rtx_cost with insn_cost and pattern_cost | expand |
On 10/09/2017 01:35 PM, Segher Boessenkool wrote: > This adds a new hook that the insn_cost function uses if a target has > implemented it (it uses the old pattern_cost nee insn_rtx_cost if not). > > I'll commit this now; it was okayed by Jeff at > https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00204.html . > > > Segher > > > 2017-10-09 Segher Boessenkool <segher@kernel.crashing.org> > > * target.def (insn_cost): New hook. > * doc/tm.texi.in (TARGET_INSN_COST): New hook. > * doc/tm.texi: Regenerate. > * rtlanal.c (insn_cost): Use the new hook. As a target maintainer, I'm kind of confused by this patch, and I don't think the tm.texi change gives sufficient guidance about the default hook behavior, how it interacts with TARGET_RTX_COSTS and/or TARGET_ADDRESS_COST, or the different contexts the three hooks are used in. Do target maintainers need to do something to define this new hook to prevent performance regressions? I could try to write up some advice about cost models and tuning for the internals manual, but at present I don't feel like I have any understanding of what motivated this change or how it changed the recommended practices for back end tuning. :-( -Sandra the missing-some-brain-cells
Hi! On Wed, Oct 11, 2017 at 05:39:25PM -0600, Sandra Loosemore wrote: > On 10/09/2017 01:35 PM, Segher Boessenkool wrote: > >This adds a new hook that the insn_cost function uses if a target has > >implemented it (it uses the old pattern_cost nee insn_rtx_cost if not). > As a target maintainer, I'm kind of confused by this patch, and I don't > think the tm.texi change gives sufficient guidance about the default > hook behavior, how it interacts with TARGET_RTX_COSTS and/or > TARGET_ADDRESS_COST, or the different contexts the three hooks are used > in. Do target maintainers need to do something to define this new hook > to prevent performance regressions? No, everything works as it did if you don't do anything. Should I add a little bit of documentation what the hook does by default? It may be good as a scary story, to get more ports to use their own hook implementation instead ;-) > I could try to write up some advice about cost models and tuning for the > internals manual, but at present I don't feel like I have any > understanding of what motivated this change or how it changed the > recommended practices for back end tuning. :-( insn_rtx_cost did not work with instructions: it worked with instruction _patterns_. It also does not work for anything but single-set and similar patterns (not the same as single_set, that requires an instruction!) It also is really hard to write a TARGET_RTX_COSTS that properly describes the cost of the machine instructions you have (and to keep it updated!) With these patches combine can make better decisions already (no longer do many instructions have "unknown" cost). I am planning to move more users of TARGET_RTX_COSTS over to insn_cost, or even get the needed info in a more direct way. This will take time; all help is welcome :-) Segher
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi index 8f503e1..0377217 100644 --- a/gcc/doc/tm.texi +++ b/gcc/doc/tm.texi @@ -6652,6 +6652,18 @@ should probably only be given to addresses with different numbers of registers on machines with lots of registers. @end deftypefn +@deftypefn {Target Hook} int TARGET_INSN_COST (rtx_insn *@var{insn}, bool @var{speed}) +This target hook describes the relative costs of RTL instructions. + +In implementing this hook, you can use the construct +@code{COSTS_N_INSNS (@var{n})} to specify a cost equal to @var{n} fast +instructions. + +When optimizing for code size, i.e.@: when @code{speed} is +false, this target hook should be used to estimate the relative +size cost of an expression, again relative to @code{COSTS_N_INSNS}. +@end deftypefn + @deftypefn {Target Hook} {unsigned int} TARGET_MAX_NOCE_IFCVT_SEQ_COST (edge @var{e}) This hook returns a value in the same units as @code{TARGET_RTX_COSTS}, giving the maximum acceptable cost for a sequence generated by the RTL diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in index 15b3f1f..d2cf68f 100644 --- a/gcc/doc/tm.texi.in +++ b/gcc/doc/tm.texi.in @@ -4600,6 +4600,8 @@ Define this macro if a non-short-circuit operation produced by @hook TARGET_ADDRESS_COST +@hook TARGET_INSN_COST + @hook TARGET_MAX_NOCE_IFCVT_SEQ_COST @hook TARGET_NOCE_CONVERSION_PROFITABLE_P diff --git a/gcc/rtlanal.c b/gcc/rtlanal.c index f01eab5..eadf691 100644 --- a/gcc/rtlanal.c +++ b/gcc/rtlanal.c @@ -5329,6 +5329,9 @@ pattern_cost (rtx pat, bool speed) int insn_cost (rtx_insn *insn, bool speed) { + if (targetm.insn_cost) + return targetm.insn_cost (insn, speed); + return pattern_cost (PATTERN (insn), speed); } diff --git a/gcc/target.def b/gcc/target.def index 80ef746..aac5d27 100644 --- a/gcc/target.def +++ b/gcc/target.def @@ -3715,6 +3715,20 @@ registers on machines with lots of registers.", int, (rtx address, machine_mode mode, addr_space_t as, bool speed), default_address_cost) +/* Compute a cost for INSN. */ +DEFHOOK +(insn_cost, + "This target hook describes the relative costs of RTL instructions.\n\ +\n\ +In implementing this hook, you can use the construct\n\ +@code{COSTS_N_INSNS (@var{n})} to specify a cost equal to @var{n} fast\n\ +instructions.\n\ +\n\ +When optimizing for code size, i.e.@: when @code{speed} is\n\ +false, this target hook should be used to estimate the relative\n\ +size cost of an expression, again relative to @code{COSTS_N_INSNS}.", + int, (rtx_insn *insn, bool speed), NULL) + /* Give a cost, in RTX Costs units, for an edge. Like BRANCH_COST, but with well defined units. */ DEFHOOK