Georg-Johann Lay <a...@gjlay.de> writes: > Richard Sandiford schrieb: >> I've been working on some patches to make insn_rtx_cost take account >> of the cost of SET_DESTs as well as SET_SRCs. But I'm slowly beginning >> to realise that I don't understand what rtx costs are supposed to represent. >> >> AIUI the rules have historically been: >> >> 1) Registers have zero cost. >> >> 2) Constants have a cost relative to that of registers. By extension, >> constants have zero cost if they are as cheap as a register. >> >> 3) With an outer code of SET, actual operations have the cost >> of the associated instruction. E.g. the cost of a PLUS >> is the cost of an addition instruction. >> >> 4) With other outer codes, actual operations have the cost >> of the combined instruction, if available, or the cost of >> a separate instruction otherwise. E.g. the cost of a NEG >> inside an AND might be zero on targets that support BIC-like >> instructions, and COSTS_N_INSNS (1) on most others. >> >> [...] >> >> But that hardly seems clean either. Perhaps we should instead make >> the SET_SRC always include the cost of the SET, even for registers, >> constants and the like. Thoughts? > > 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. Also, any change along these lines is similar to the "tie costs to .md patterns" thing that I mentioned at the end of the message. I don't really have time to work on anything so invasive, so the question is really whether we can sensibly change the costs within the current framework. > E.g. the cost of a CONST_INT is meaningless if you don't know what to do > with the constant. (set (reg:QI) (const_int 0)) might have different > cost than (set (reg:SI) (const_int 0)). That's the old modeless-CONST_INT problem though. I agree the mode makes a difference, but I think it's a separate issue. If we did pass complete instructions, each caller would have to provide a SET whose SET_DEST is an arbitrary psuedo register of the required mode. In all likelihood, we'd define a new utility function do this for us. So in the modeless-CONST_INT world, we would need to pass the mode to that utility function. But if we're prepared to pass such extra information around, we could simply do it by passing the mode directly to rtx_cost. I think the cost of a full rvalue (rather than a complete SET), should be based on the assumption that the destination is a register. So I don't the backend is missing any information in that respect. I.e. the problem doesn't seem to be lack of information, but rather lack of consistency (between registers, constants, operators, and so on). > Similar applies for an addition if you don't know if it's for > arithmetic or address offset computation inside a MEM. Yeah, that'd be bad, but I don't think we take costs at that level. Only a few places take the cost of anything "smaller" than a complete rvalue, and they either take the cost of a condition or take the cost of an operand to a "top-level" operator. The target then has the option of stopping the recursion whenever it likes. Richard
