This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Sun, Jul 16, 2017 at 12:51 AM, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
> 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.

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,
> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]