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

[undefinedopcode2 at gmail dot com]

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

--- Comment #6 from Undefined Opcode <undefinedopcode2 at gmail dot com> ---
(In reply to Kewen Lin from comment #5)
> At the top of tree-ssa-loop-ivopts.cc file, there are some useful comments
> describing the costs for iv candidate itself and group, it may help.
> 
> <Candidate Costs>:
>   cand  cost
>   0     5
>   1     5
>   2     5
>   3     4
>   4     5
>   5     5
>   6     5
>   7     5
>   8     5
> 
> This part is for "variable costs".
> 
> <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;
> 
> This part is for "group/use costs".
> 
> There would be no dumping for a candidate when it has infinite cost for the
> group, so the above means only candidate 0, 7 and 8 are valid to be used for
> group 0.
> 
> Final cost looks like:
> 
>     cost: 7 (complexity 0)
>     reg_cost: 2
>     cand_cost: 5
>     cand_group_cost: 0 (complexity 0)
>     candidates: 7
>      group:0 --> iv_cand:7, cost=(0,0)
>      group:1 --> iv_cand:7, cost=(0,0)
>     invariant variables:
>     invariant expressions:
> 
> ----
> 
> By quick checking, it looks the inf cost for the pair (cand 3, group 0) is
> due to:
> 
>   /* Check if we have enough precision to express the values of use.  */
>   if (TYPE_PRECISION (utype) > TYPE_PRECISION (ctype))
>     return infinite_cost;

Some debug prints confirm this is indeed what's happening, the pass thinks
candidate 3 is trying to fit a 32-bit value into 16-bits and bails. What's not
clear to me is why. Does it have some notion of -1 requiring 32-bits to store
even though it'll fit just fine in 16 for our purposes?