Richard Sandiford 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.
RTX costs only make sense if the rtx eventually results in insns. This can basically happen in two ways: * expander which transforms insn-like expression to a sequence of insns. Example is x << y in some backend that cannot do it natively and expand it into loop. Similar example is X + big_const which cannot be handled by target, i.e. insn predicate denies it. * cooking up new insns like in insn combine. It only makes sense to query costs for insns that actually match, i.e. pass recog or recog_for_combine or whatever. > 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 don't see benefit of recursion because every step removes information. E.g. in the example you gave in http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01264.html which is cost of shifts like x << ? the operand number does not help because you need the second operand to determine the cost: shift by constant offset in general has different cost than shift by variable. Thus, only the complete RTX makes sense for cost computation. In general it's not possible to separate the cost function because cost (f(a,b)) != cost (f) + cost (a,0) + cost (b,1) resp. you cannot represent costs in that orthogonal way and such an ansatz must fail. There are also cases where costs are paradoxical, i.e. a more complex expression has lower costs than a simpler one. Example is bit extraction which might be cheaper than shifting the mask plus oring/anding. BTW, avr BE does recursion inside rtx_costs which is bad idea, imo. But that's up to the target. Johann > Richard
