Hans-Peter Nilsson <h...@bitrange.com> writes: > On Wed, 17 Aug 2011, Richard Sandiford wrote: >> It also means >> that constants that are slightly more expensive than a register -- >> somewhere in the range [0, COSTS_N_INSNS (1)] -- end up seeming >> cheaper than registers. > > Yes, perhaps some scale factor has to be applied to get > reasonable cost granularity in an improved cost model for the > job... Some constants *are* more expensive (extra words and/or > extra cycles), yet preferable to registers for one (or maybe two > or...) insns. You don't want to find that all insns except > constant-loads suddenly use register arguments and no > port-specific metric way to tweak it. Mentioned for the record.
I was hoping that if the costs of SETs were "fixed", then that kind of situation should work without any new scale factors. E.g. two constant moves of equal execution frequency that cost COSTS_N_INSNS (1) + 1 (total COSTS_N_INSNS (2) + 2) shouldn't be CSEd (COSTS_N_INSNS (3) + 1) unless the single constant move can go in a less frequently-executed block. > I don't think you can get into trouble for trying to improve > this area for consistency: between releases a port already > usually arbitrarily loses on some type of codes and costs have > to be re-tweaked, unless performance is closely tracked. Yeah, probably true. Certainly a good excuse for me to use. :-) > Aiming for traceability can only help (like, "read the added doc > blurb on how to define the port RTX costs instead of gdb > stepping and code inspection"). Yeah, that'd be nice. In practice there's probably always going to be a bit of experimentation needed. E.g. getting the cost of multiplicaton correct wrt shifts and adds can be tricky on a superscalar target. (At least, it was when I last tried it too many years ago.) Richard
