https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84650
--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> --- On Sat, 3 Mar 2018, amker at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84650 > > --- Comment #3 from amker at gcc dot gnu.org --- > So given below dump before sccp: > > <bb 2> [local count: 14598063]: > > <bb 3> [local count: 118111601]: > # eu_19 = PHI <0(2), eu_13(7)> > > <bb 4> [local count: 955630224]: > # dj.1_18 = PHI <0(3), _1(8)> > _1 = dj.1_18 + 1; > if (_1 <= 1) > goto <bb 8>; [89.00%] > else > goto <bb 5>; [11.00%] > > <bb 8> [local count: 850510900]: > goto <bb 4>; [100.00%] > > <bb 5> [local count: 118111601]: > # _2 = PHI <_1(4)> > _4 = _2 != 3; > _5 = (unsigned int) _4; > _15 = 1 - _5; > eu_13 = _15 + eu_19; > if (eu_13 <= 1) > goto <bb 7>; [87.64%] > else > goto <bb 6>; [12.36%] > > <bb 7> [local count: 103513538]: > goto <bb 3>; [100.00%] > > <bb 6> [local count: 14598063]: > # _25 = PHI <_2(5)> > dj = _25; > return; > > before sccp, e_13, _15 and e_19 was identified as: > e_13: {_15, _15} > _15 : _15 > e_19: {0, _15} > > During sccp, it proves _15 equals to 0 and thus: > e_13: 0 > _15 : 0 > e_19: {0, _15} > > This information is cached and used in ivopts. I see scev_reset () being called multiple times between sccp and ivopts so I doubt that. The SCEV cache isn't reset between GRAPHITE and IVOPTs though and LIM after GRAPHITE moves some expressions. Testing a fix.
