On Mon, Aug 22, 2011 at 10:19 AM, Richard Sandiford <richard.sandif...@linaro.org> wrote: > Georg-Johann Lay <a...@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 >
