This is the mail archive of the
mailing list for the GCC project.
Re: [rfc] slightly better reload constant rematerialization
- From: Ian Lance Taylor <ian at airs dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: 20 Jan 2005 14:46:47 -0500
- Subject: Re: [rfc] slightly better reload constant rematerialization
- References: <20050120034538.GA14946@redhat.com>
Richard Henderson <email@example.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