Re: [rfc] slightly better reload constant rematerialization

[Ian Lance Taylor <ian at airs dot com>]

Richard Henderson <rth@redhat.com> writes:

> The following patch hacks at the problem in push_reload.  It does 
> not take into account the cost of the constant, which arguably
> could be high in some cases and less desirable than just a copy.
> It's good enough for Alpha, though, and I'm wondering what other
> folks think of this for other platforms.  If we need cost metrics,
> what form should they take?

Obviously there are platforms where it can be expensive to create a
constant, so just checking CONSTANT_P wouldn't seem to be enough to
make the right decision.  The natural cost metrics to use would seem
to be REGISTER_MOVE_COST and rtx_cost.  Of course, as far as I know,
we've never before said that those costs were commensurable.

To state the obvious, costs in general are a rather nebulous concept
right now.  As far as I can tell they are mostly set by trial and
error.  And on modern processors to cost of a single instruction is in
any case not too meaningful, as the context matters a great deal.

I kind of feel that a comparison model would work better, in which we
can say "which is better: instruction sequence 1 or instruction
sequence 2?"  Then even in the current reductionist case of a single
instruction or just part of one, we can still hopefully make more
intelligent decisions rather than doing trial and error tinkering with
cost values.

Ian