This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Just what are rtx costs?
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
>