Strength reduction costs for autoincrement generation

[Michael Hayes <mhayes at redhat dot com>]

Sometime in the last month or so, autoincrements stopped being
generated for the c4x target.  This probably happened when the rtx
costs were reworked.  I've had a bit of a squizz to see what is going
wrong and found what is strangling things is the test that benefit is
greater than 0 in this bit of code within loop_giv_reduce_benefit:

#ifdef AUTO_INC_DEC
  /* Attempt to guess whether autoincrement will handle some of the
     new add insns; if so, increase BENEFIT (undo the subtraction of
     add_cost that was done above).  */
  if (v->giv_type == DEST_ADDR
      /* Increasing the benefit is risky, since this is only a guess.
	 Avoid increasing register pressure in cases where there would
	 be no other benefit from reducing this giv.  */
      && benefit > 0
      && GET_CODE (v->mult_val) == CONST_INT)
    {
...

If I bias this test so (benefit + add_cost) > 0 then everything works
sweetly for me.  Is anyone else seeing similar problems?

Here's a testcase, a simple vector dot-product:

double foo (double *a, double *b, int size)
{
  double total = 0.0;
  int i;

  for (i = 0; i < size; i++)
    {
      total += a[i] * b[i];
    }
  return total;
}

This generates two reg+reg mem givs for the two array references.
Each giv is assigned a benefit of 1 (the cost of a reg+reg addressing
mode minus the cost of a reg addressing mode).  The benefit is then
decremented by 4, the cost of an add insn, giving a value of -3.  Now
since this is less than zero, the code to recoup the cost of the add
insn is not added and this giv never gets reduced :-(

I can overome this problem by grossly exaggerating the address cost of
a reg+reg but this lies to the compiler in other places. 

What the calculation does not take into account is the cost of
incrementing the biv in these reg+reg cases, since in the case of the
c4x, the biv needs to be assigned to a special index register.

Michael.