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

[Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>]

On 26/07/17 18:54, Jeff Law wrote:
> On 07/17/2017 02:35 PM, Richard Henderson wrote:
>> On 07/17/2017 12:20 AM, Richard Biener wrote:
>>> On Sun, Jul 16, 2017 at 12:51 AM, Segher Boessenkool
>>>> 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 ...
>>
>> 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.
> 
> Jeff
> 

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

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.

R.