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

[Richard Henderson <rth at twiddle dot net>]

On 08/02/2017 12:34 PM, Richard Earnshaw wrote:
> I'm not sure if that's a good or a bad thing.  Currently the mid-end
> depends on some rtx constructs having sensible costs even if there's no
> rtl pattern to match them (IIRC plus:QI is one such construct - RISC
> type machines usually lack such an instruction). 

I hadn't considered this... but there are several possible workarounds.

The simplest of which is to fall back to using rtx_cost if the insn_cost hook
returns a failure indication, e.g. -1.

> Also, costs tend to be
> micro-architecture specific so attaching costs directly to patterns
> would be extremely painful, adding support would require touching the
> entirety of the MD files.  The best bet would be a level of indirection
> from the patterns to cost tables, much like scheduler attributes.

I was never thinking of adding costs directly to the md files, but rather
structuring the insn_cost hook like

  if (recog_memoized (insn) < 0)
    return -1;
  switch (get_attr_type (insn))
    {
    case TYPE_iadd:
    case TYPE_ilog:
    case TYPE_mvi:
      return COSTS_N_INSNS (1);

    case TYPE_fadd:
      return cost_data->fp_add;
    }

etc.  This would be especially important when it comes costing for simd-type
insns.  Matching many of those any other way would be fraught with peril.

> But that still leaves the issue of what to do with the cost of MEM vs
> REG operands - in a pattern they may both be matched by general_operand
> but the cost of each is quite distinct and the normal attributes system
> probably won't (maybe can't) disambiguate the sub-types until after
> register allocation.

Pre-reload we'll probably have a pseudo and assume a register operand, or have
an unambiguous memory.  I don't think that's really a problem.  We're producing
a cost estimate based on what we are given at that moment.

It does make x86 more complex than more RISC-ier targets, but still not
impossible.  There is at least a "memory" attribute with which one could adjust
the base cost selected by the "type" attribute.

One could also walk the pattern to count the number of mems, at least for a
given subset of insn types.


r~