https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87288
--- Comment #4 from bin cheng <amker at gcc dot gnu.org> ---
In dump for IVOPTs, there is niter analyzed like:
Applying pattern match.pd:1651, generic-match.c:16009
Analyzing # of iterations of loop 1
exit condition [1, + , 1](no_overflow) < bnd.8_41
bounds on difference of bases: 0 ... 2147483646
Applying pattern match.pd:1111, generic-match.c:115
Applying pattern match.pd:1167, generic-match.c:16905
Applying pattern match.pd:108, generic-match.c:50
result:
# of iterations bnd.8_41 + 4294967295, bounded by 2147483646
number of iterations bnd.8_41 + 4294967295
for below GIMPLE:
<bb 5> [local count: 105119324]:
niters.6_33 = (unsigned int) n_14;
ni_gap.7_40 = niters.6_33 + 4294967295;
bnd.8_41 = ni_gap.7_40 >> 1;
<bb 4> [local count: 567644349]:
# vectp.11_44 = PHI <vectp.11_45(6), _10(5)>
# vectp_jacobianTransposeds.15_51 = PHI <vectp_jacobianTransposeds.15_52(6),
&jacobianTransposeds(5)>
# ivtmp_54 = PHI <ivtmp_55(6), 0(5)>
vect__5.13_46 = MEM[(double *)vectp.11_44];
vectp.11_47 = vectp.11_44 + 16;
vect__5.14_48 = MEM[(double *)vectp.11_47];
vect_perm_even_49 = VEC_PERM_EXPR <vect__5.13_46, vect__5.14_48, { 0, 2 }>;
MEM[(double &)vectp_jacobianTransposeds.15_51] = vect_perm_even_49;
vectp.11_45 = vectp.11_47 + 16;
vectp_jacobianTransposeds.15_52 = vectp_jacobianTransposeds.15_51 + 16;
ivtmp_55 = ivtmp_54 + 1;
if (ivtmp_55 >= bnd.8_41)
goto <bb 12>; [16.67%]
else
goto <bb 6>; [83.33%]
So # of iterations is wrong, it should be:
bnd.8_41 == 0 ? 0 : bnd.8_41 + 4294967295
This is because bounds is wrongly computed by below code:
// iv1->base = bnd.8_4;
// iv0->base =0;
bound_difference (loop, iv1->base, iv0->base, &bnds);
because of wrong range information for bnd.8_4 as in dump for slp1:
;; basic block 5, loop depth 0, count 105119324 (estimated locally), maybe
hot
;; prev block 3, next block 4, flags: (NEW, VISITED)
;; pred: 2 [89.0% (guessed)] count:105119324 (estimated locally)
(FALSE_VALUE,EXECUTABLE)
niters.6_33 = (unsigned int) n_14;
ni_gap.7_40 = niters.6_33 + 4294967295;
# RANGE [1, 2147483647] NONZERO 2147483647
bnd.8_41 = ni_gap.7_40 >> 1;
Seems to me bnd.8_41 can take value ZERO.
Is this related to changes in VRP? Thanks.
