Ian Lance Taylor <i...@google.com> writes: > pocma...@gmail.com (Paulo J. Matos) writes: > >> Moreover, is there a reason for the existence of COST_N_INSNS(x) and why >> this multiplies x by 4? Is 4 just a special number? Any reason on why I >> should be using COST_N_INSNS instead of just assigning *total (of >> target_rtx_costs) to a simple integer? > > COSTS_N_INSNS is relevant because a bunch of machine independent code > uses it to compare the cost of some expression to the cost of a > register-to-register move. All such uses are somewhat dubious and > should probably be eliminated in favor of delegating all cost questions > to the backend. However, since they exist at present, you don't have to > use COSTS_N_INSNS, but you do have to be aware of it. There is nothing > special about the number 4, it's just chosen to give backends a bit of > leeway in setting the costs of operations which are not quite as > expensive as a full instruction, so that, e.g., they can assign > different costs to different addressing modes.
So, from what I understand, it seems that if there is machine independent code using COSTS_N_INSNS, I should be using it otherwise relative comparisons just don't make sense. However, from what I can see we have cost hooks for: - register move - memory move - branches - rtx - address only the last two refer to the use of COSTS_N_INSNS. How do the value for a register move (which defaults to 2), will compare to an rtx cost? Should we always use COSTS_N_INSNS for all the returned values, or for the first 3, COSTS_N_INSNS is applied on the return value? This seems to be certainly relevant for when optimising for code size. If I set a specific cost for a register move and a cost for a multiplication rtx how are they related? -- PMatos
