Re: [PATCH] PR target/19597: Rewrite AVR backend's rtx_costs

[Paul Schlie <schlie at comcast dot net>]

re: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01698.html

> Roger Sayle wrote:
> The following patch resolves PR target/19597 which is a code size
> regression in gcc 4.0 on AVR when using -Os.  The problem is caused
> by the avr backend returning pseudo-random numbers for rtx_cost
> which interferes with the middle-end's improved optimization tuning.

In hopes that a more accurate instruction cost estimate will improve
instruction selection, it may be better to be somewhat more conservative
estimating the cost of a CONST_INT, as QI-mode constants are arguably
only cheap if 0, or restricted to r16-31 (which tend to be allocated
to call arguments). So wonder if a tweak to the patch like below might
be prudent; thereby identifying constants as slightly more expensive on
the average than existing register operands, but not so much so that it
becomes broadly preferable to spill otherwise active register operands
in favor of being allocated to less-active constants (?):

    switch (code)
      {
      case CONST_INT:
+     case CONST_DOUBLE:
-  !    *total = TARGET_INT8 ? COSTS_N_INSNS (1) : COSTS_N_INSNS (2);
+  !    *total = 1 + COSTS_N_INSNS (GET_MODE_SIZE (mode));
   !    return true;

   +  case MEM:
      case CONST:
      case LABEL_REF:
      case SYMBOL_REF:
-     case CONST_DOUBLE:
   !    *total = COSTS_N_INSNS (GET_MODE_SIZE (mode));
        return true;

   !  case NEG:
   !    switch (mode)

For mult, as I believe !AVR_ENHANCED implies add&shift loop, possibly:

   !  case MULT:
+       if (AVR_ENHANCED)
+         *total = COSTS_N_INSNS ( 4 * GET_MODE_SIZE (mode) );
+       else
+         *total = COSTS_N_INSNS ( 16 * GET_MODE_SIZE (mode) );
-  !    switch (mode)
-  !    {
-  !    case QImode:
-  !      if (AVR_ENHANCED)
-  !        *total = COSTS_N_INSNS (optimize_size ? 3 : 4);
-  !      else if (optimize_size)
-  !        *total = COSTS_N_INSNS (AVR_MEGA ? 2 : 1);
-  !      else
-  !        return false;
-  !
-  !    case HImode:
-  !      if (AVR_ENHANCED)
-  !        *total = COSTS_N_INSNS (optimize_size ? 7 : 10);
-  !      else if (optimize_size)
-  !        *total = COSTS_N_INSNS (AVR_MEGA ? 2 : 1);
-  !      else
-  !        return false;
-  !
-  !    default:
-  !      return false;
-  !    }
   !    *total += avr_operand_rtx_cost (XEXP (x, 0), mode, code);
   !    *total += avr_operand_rtx_cost (XEXP (x, 1), mode, code);
   !    return true;

And div, etc., possibly (assuming counting ~ instruction-cycles):

   !  case DIV:
   !  case MOD:
   !  case UDIV:
   !  case UMOD:
+         *total = COSTS_N_INSNS ( 16 * GET_MODE_SIZE (mode) );
-  !    if (optimize_size)
-  !      *total = COSTS_N_INSNS (AVR_MEGA ? 2 : 1);
-  !    else
-  !      return false;
   !    *total += avr_operand_rtx_cost (XEXP (x, 0), mode, code);
   !    *total += avr_operand_rtx_cost (XEXP (x, 1), mode, code);
   !    return true;

(which does seem to help in general, and presumably it's purpose; but also
 note that under no circumstances would I ever expect shift loops to ever
 be unwound to reflect the estimated shift costs given for !optimize_size,
 I hope; as there's little arguable benefit to ever unwinding loops to be
 larger than ~8-10 instructions in size for a lightly pipelined machine like
 avr, but it's not clear if unwinding is constrained by these estimates, or
 if it may be beneficial to estimate average likely vs worst-case costs?)