Re: [patch] RFC: Hook for insn costs?

[Segher Boessenkool <segher at kernel dot crashing dot org>]

Hi!

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
> PARALELLs.
> 
> 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
instruction.

So I argue that we want to have a hook for insn cost.

Now what should it take as input?  An rtx_insn, or just the pattern
(as insn_rtx_cost does)?  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,
etc.)?

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.


Segher