https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84650
--- Comment #5 from amker at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #4) > 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. Hmm, in this case the problem is in scev, which doesn't fold {0, _15} given _15 is known to be zero? > > Testing a fix. Thanks for helping.