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? Richard
