Re: Signed divide by 2 pessimization

[Marek Michalkiewicz <marekm at linux dot org dot pl>]

Geoff Keating <geoffk@cygnus.com> wrote:
> 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.

Thanks for explaining this - these different cost units are a bit
confusing.

COSTS_N_INSNS(N) is now defined as ((N) * 2), and that seems to be
consistent with what I noticed (better code for signed divide by 2
after changing x86 BRANCH_COST from 1 to 2).

The COSTS_N_INSNS macro is only defined in cse.c - would it be OK
to move it to rtl.h (where other functions from cse.c are already
declared) or some other include file, so it can be used elsewhere?
I'm not quite sure how to change rtx_cost just yet, so it seems
easier to just use COSTS_N_INSNS (BRANCH_COST) directly.

I see that at least config/arm/arm.c needs it, and defines it itself
differently (probably should be updated after the 2000-09-06 change
in cse.c).  If COSTS_N_INSNS is made available in expmed.c, it could
be used to scale BRANCH_COST in the test which I'd like to change:

  if (COSTS_N_INSNS (BRANCH_COST) < shift_cost[size - 1] * (abs_d != 2)
				    + shift_cost[size - lgup])
    {
      /* branch and fewer shifts */
    }
  else
    {
      /* no branch, more shifts */
    }

Would something like this be OK?  Should do the right thing on x86
as COSTS_N_INSNS (BRANCH_COST) is 2 there, and I can play with shift
costs on the AVR to make it do the right thing here too.

(As a side note, this place in expmed.c is indented very far to the
right - wouldn't it be a good idea to split expand_divmod in a few
smaller functions?  Or is this function deliberately so big, for speed?)

> 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.

If we do it right the first time soon - certainly.

But I'm worried that it is not easy to fix it properly.  If it never
happens because "someone" doesn't exist (not enough motivation because
the important targets happen to work well), I'd like to at least have
the hack now - it already exists, and is better than nothing...

Thanks,
Marek