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.

Reply via email to