This is the mail archive of the
mailing list for the GCC project.
Re: [patch] RFC: Hook for insn costs?
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: Georg-Johann Lay <avr at gjlay dot de>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Mon, 17 Jul 2017 12:20:16 +0200
- Subject: Re: [patch] RFC: Hook for insn costs?
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <20170715225119.GA13471@gate.crashing.org>
On Sun, Jul 16, 2017 at 12:51 AM, Segher Boessenkool
> On Wed, Jul 12, 2017 at 03:15:09PM +0200, Georg-Johann Lay wrote:
>> the current cost computations in rtlanal.c and maybe other places
>> suffer from the fact that they are hiding parts of the expressions
>> from the back-end, like SET_DESTs of single_set or the anatomy of
>> Would it be in order to have a hook like the one attached?
>> I am aware of that, in an ideal world, there wouldn't be more
>> than one hook to get rtx costs. But well...
> The number of hooks is not a problem. The overall complexity of this
> interface (between the backends and optimisers; a group of related
> hooks) _is_ a problem. Also, the interface should be good for all
> targets, easy to use, do one thing and do it well.
> Currently we have rtx_costs, which computes an estimated cost for any
> expression. In most cases what we want to compute is the cost of an
> instruction though! It can be a single set (in which case the
> expression cost is a reasonable approximation), but it also can be
> something else (like, a parallel). Also, on many targets at least,
> it is *much* easier to compute the cost knowing that this is a valid
> So I argue that we want to have a hook for insn cost.
And I think at previous GNU Cauldrons we agreed to that.
> Now what should it take as input? An rtx_insn, or just the pattern
> (as insn_rtx_cost does)?
Is there any useful info on the other operands of an rtx_insn? If not
then passing in the pattern (a rtx) might be somewhat more flexible.
Of course it's then way easier to confuse rtx_cost and insn_cost ...
> And if an rtx_insn, should that than be an
> rtx_insn that is already linked into the insn chain (so we can see what
> other insns generate its inputs, and which of its outputs are unused,
> One comment about your patch:
>> +/* A magic value to be returned by TARGET_INSN_COSTS to indicate that
>> + the costs are not known or too complicated to work out there. */
>> +#define INSN_COSTS_UNKNOWN (-1234567)
> Why not just -1? And is 0 really so terrible; in the extremely rare
> case we really want cost 0, it won't hurt much saying "unknown", as we
> do currently. For "hook unimplemented", just set the hook to NULL.