On 10/02/14 02:31, Ramana Radhakrishnan wrote:
And a couple of items caught my attention.
For one the backend doesn't set the costs of a reg-reg move to be the
same as a reg-const move. In the AArch64 backend the approach appears to
be in line with the documentation which is to set the costs of various
instructions relative to a fast integer instruction. The hack to
aarch64.c in the attached patch is for setting the cost properly for a
reg-reg move of the appropriate mode and is only for demonstration
purposes. I expect this to be replaced by an equivalent bit of code in
the backend to achieve the same thing.
rtx_cost and its friends have always been a problem and it's always felt
like a design problem. The true cost of something is so context
dependent I'm not really sure how to build an API to do this in a sane way.
Regardless, the first thing I see when I look at the aarch64 rtx costing
bits is that it rarely looks at modes. So it's entirely possible that
if floats/doubles have a higher cost than integers that it needs a bit
of hacking to bring the result into line for non-integer modes.
However the code in precompute_register_parameters assumes that the
value is forced into a register if the set_src_cost of a constant is >
COSTS_N_INSNS(1). Now this appears to be checking the cost of a set of
an FP immediate constant to a register and the backend not unreasonably
sets it to an appropriate cost. Now to assume that this number should
always be less than 1 is really not appropriate.
Agreed. Also note there's a bit of a break in the model -- namely that
we're comparing the cost of a particular operand vs the cost of insns.
I've always found this to be, umm lame and a source of confusion when
folks have been doing backend tuning.
Instead of putting in what's effectively a lie in the backend, should we
just be moving the midend to a world where all such numbers are compared
to costs from the backend rather than relying on magic numbers. The
costs comparison logic is similar to whats used in lower-subreg. The
thought was to move this to a common area (Richard Sandiford suggested
expmed.h in a private conversation) so that we had common APIs to check
the cost of a SET in this form rather than relying on the rtx_cost
interface.
Agreed.
Jeff
