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?
