[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 #3 from Undefined Opcode <undefinedopcode2 at gmail dot com> ---
Created attachment 53348
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53348&action=edit
dump of buggy optimization pass

(In reply to Andrew Pinski from comment #2)
> I suspect this is a target cost model issue ...
> 
> You can look at the ivopts dump to see the costs there.

Funny, I was just about to reply to the thread about this. It looks like it's
choosing candidate 7. I've also included the candidate 3 info for completeness.
Candidate 3:
  Incr POS: orig biv
  IV struct:
    Type:       short int
    Base:       15
    Step:       -1
    Biv:        N
    Overflowness wrto loop niter:       No-overflow
...
<trimmed>
...
Candidate 7:
  Var befor: ivtmp.19
  Var after: ivtmp.19
  Incr POS: before exit test
  IV struct:
    Type:       unsigned int
    Base:       15
    Step:       4294967295
    Biv:        N
    Overflowness wrto loop niter:       Overflow
...
<trimmed>
...
<Candidate Costs>:
  cand  cost
  0     5
  1     5
  2     5
  3     4
  4     5
  5     5
  6     5
  7     5
  8     5

It's odd to me that it's choosing 7 over 3, since 3 is clearly lower cost. It
also spits out "group candidate costs", but I'm not sure what those actually
represent (sorry, this is my first time poking through GCC optimization
internals).

I've attached a copy of test.c.174t.ivopts if someone else can make more sense
of it.