Re: Signed divide by 2 pessimization

[Geoff Keating <geoffk at cygnus dot com>]

> From: Marek Michalkiewicz <marekm@linux.org.pl>
> Date: Sun, 10 Sep 2000 13:01:16 +0200 (CEST)
> CC: marekm@linux.org.pl, gcc@gcc.gnu.org
> 
> Geoff Keating <geoffk@cygnus.com> wrote:
> > This is a sign that x86 should be fixed.  It's bad to work around
> > problems with a backend in the frontend.  Why is the x86 BRANCH_COST
> > set too low?
> 
> That was just my conclusion after some simple tests I did on a
> Pentium III.  But the x86 is a complicated beast, and probably
> there is no single value of BRANCH_COST that is best in all cases.
> (This was already discussed in May.)
> 
> What I did was to change the test to look like this:
> 
>   (BRANCH_COST < shift_cost[size - 1] * (abs_d != 2) + shift_cost[size - lgup])
> 
> (compare the cost of a branch with the cost of one or two shifts)

BRANCH_COST and shift_cost are in different units.  shift_cost is in
the units defined by rtx_cost, in which one register-register insn is
approximately 4 units.  BRANCH_COST is 1 by default, meaning a branch
is equivalent to about one other insn.

Probably the right thing to do is enhance rtx_cost so that it can
provide the cost of a branch insn itself (by default this would be
COSTS_N_INSNS (BRANCH_COST) ), and use that.

> I don't even know what would be the effect of this change on dozens
> of other GCC targets, or non-Intel x86 chips - I just can't test
> that.

No-one can test a change like this on every platform.  That's why you
have to assume that the backends have the correct cost definitions.

> Let's do it now, let the interested targets decide, and worry about
> improving it later.

Alternatively, how about we do it right the first time?

I really don't like the idea that we put in some hack now, and
"someone" will improve it later.  Unless you can provide that
"someone" you have to assume that it will never be fixed.

-- 
- Geoffrey Keating <geoffk@cygnus.com>