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

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

On Wed, Aug 02, 2017 at 08:34:20PM +0100, Richard Earnshaw wrote:
> >> A lot of really complex by-hand pattern matching goes away if you know
> >> the instruction is valid, and you can look up an insn attribute.  That
> >> suggests passing the insn and not the PATTERN.
> > Good point.  In fact, it opens the possibility that costing could be
> > attached to the insn itself as just another attribute if it made sense
> > for the target to describe costing in that manner.

I am doing this for rs6000 now, and it is totally practical.

> 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).

Yes, but in many cases a pass wants to create valid insns anyway.

I changed combine to always use insn_cost (instead of pattern_cost,
what used to be named insn_rtx_cost).  Implementation of this (for
rs6000) is much simpler: most insns just cost COSTS_N_INSNS (N) with
N the number of machine insns generated, and most others can easily
use a new attribute "cost", which for example can use the existing
rs6000_cost structure (that gives costs for various cpu models).

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

We already use the same in the rtx_costs hook; it is quite a bit nicer
to have it in the machine description itself.

I am dumping out the "old" cost and "new" cost whenever they differ.
It turns out that more than half of the differences are where the *old*
cost was bad!

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

I currently handle this directly in the insn_cost hook; it could also be
handled in the md files.  Of course this problem is easy for rs6000
because Power is purely a load-store architecture.


Segher