https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84650
--- Comment #7 from amker at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #6) > On Mon, 5 Mar 2018, amker at gcc dot gnu.org wrote: > > > 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? > > SCEV doesn't really do any folding but yeah, I'm not sure why _15 > isn't picked up as 0 here. That would be worth investigating. Ah, I kind of remember that in follow_ssa_edge_binary, it tries each operand of add operation (a_13 = _15 + e_19;). Here the case might be it finds out impossible to follow _15 to halting phi, the function then tries e_19 instead and keep _15 in its own form, thus {0, _15}. > > Note that we don't really expect unfolded/unpropagated constants > so it doesn't surprise me we see this kind of effects.
