[Bug target/106415] loop-ivopts prevents correct usage of dbra with 16-bit loop counters on m68k

["undefinedopcode2 at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106415

--- Comment #4 from Undefined Opcode <undefinedopcode2 at gmail dot com> ---
As an experiment, I added the following logic to m68k_rtx_costs():
      case PLUS:
      // <omitted a few lines related to LEA>
      if(TUNE_68000_10 && !(mode == QImode || mode == HImode))
        {
          *total = 400; // make non-byte/word ADD outrageously expensive
          return true;
        }

Sure enough, the costs for all non-short IV shot up. However, it's still
choosing candidate 7, same as before:
<Candidate Costs>:
  cand  cost
force_expr_to_var_cost size costs:
  integer 2
  symbol 4
  address 4
  other 16

force_expr_to_var_cost speed costs:
  integer 2
  symbol 4
  address 4
  other 16

  0     401
  1     5
  2     5
  3     4
  4     5
  5     5
  6     5
  7     401
  8     401

Later, when we get to group costs, the results aren't what I'd expect:
<Group-candidate Costs>:
Group 0:
  cand  cost    compl.  inv.expr.       inv.vars
  0     400     0       NIL;    NIL;
  7     0       0       NIL;    NIL;
  8     400     0       NIL;    NIL;

Group 1:
  cand  cost    compl.  inv.expr.       inv.vars
  0     0       0       NIL;    NIL;
  1     0       0       NIL;    NIL;
  2     0       0       NIL;    NIL;
  3     0       0       NIL;    NIL;
  4     0       0       NIL;    NIL;
  5     0       0       NIL;    NIL;
  6     -1      0       NIL;    NIL;
  7     0       0       NIL;    NIL;
  8     0       0       NIL;    NIL;

I'm not entirely sure what's going on here. Why does candidate 7 suddenly cost
0?