Re: Just what are rtx costs?

[Richard Guenther <richard.guenther@gmail.com>]

On Mon, Aug 22, 2011 at 10:19 AM, Richard Sandiford
<richard.sandiford@linaro.org> wrote:
> Georg-Johann Lay <avr@gjlay.de> writes:
>>>>IMO a clean approach would be to query the costs of a whole insn (resp.
>>>>it's pattern) rather than the cost of an RTX.  COSTS_N_INSNS already
>>>>indicates that the costs are compared to *insn* costs i.e. cost of the
>>>>whole pattern (modulo clobbers).
>>>
>>> The problem is that we sometimes want the cost of something that cannot
>>> be done using a single instruction.  E.g. some CONST_INTs take several
>>> instructions to create on MIPS.  In this case the costs are really
>>> measuring the cost of an emit_move_insn sequence, not a single insn.
>>>
>>> I suppose we could use emit_move_insn to create a temporary sequence
>>> and sum the cost of each individual instruction.  But that's potentially
>>> expensive.
>>
>> No, that complexity is not needed.  For (set (reg) (const_int)) the BE
>> can just return the cost of the expanded sequence because it knows how
>> it will be expanded and how much it will cost.  There's no need to
>> really expand the sequence.
>
> Sorry, I'd misunderstood your suggestion.  I thought you were suggesting
> that the rtx costs functions should only be presented with SETs that are
> valid instructions.  I hadn't realised that you were still allowing these
> SETs to be arbitrary ones that have been cooked up by the optimisers.
>
> So are you saying that we should remove the recursive nature of the
> rtx_cost/targetm.rtx_costs interface, and have the backend handle any
> recursion itself?  I.e. targetm.rtx_costs only ever sees a complete
> (but perhaps invalid) instruction pattern?  Or would you still keep
> the current recursion?

I would say yes to that - kill the recursion.

Richard.

> Richard
>