This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfc] slightly better reload constant rematerialization


Richard Henderson <rth@redhat.com> writes:

> > 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.
> 
> I don't think I understand.  How do we compare the sequences if not
> by some abstract cost metric?

We want to choose between, say, a sequence of PLUS instructions vs. a
single MULT instruction.  We carefully pick cost values so that the
right number of PLUS instructions is better than the MULT instruction.
So we've nailed down those values.  Now we have to compare against a
DIV instruction.  So we have to nail down a cost for that such that we
make the right choice for division by large constants.  Then we're
asked about some addressing mode which uses PLUS and MULT, and we have
to get the nailed down cost values to make the right decision there
too.

Then over the years we notice particular sequences where we make the
wrong decision, so we tweak the costs to make the right decision.  And
then we tweak them again, and again.  But each time we tweak them we
don't check that we haven't broken the last set of tweaks, because we
don't remember them.

If we are comparing code sequences, instead of using costs to do the
comparison, we can nail down particular choices and always make the
same decision for them.

Yes, we still have to use an abstract cost metric for choices which
haven't nailed down.  In fact, we start with the same cost metric we
use today.  But now, as we tweak it, it gets monotonically better,
instead of gyrating around a complex set of decisions.

Also, the current cost metric doesn't let us compare sequences of
instructions.  For example, we may happen to know that we can do an
add and a multiply in a single cycle, but that two adds or two
multiplies take two cycles.  How do we express that kind of thing
using the cost metrics we have today?

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]