https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359
--- Comment #29 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 2 Mar 2018, aldyh at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359 > > --- Comment #28 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #25) > > > > What usually makes things complicated in the end is when for an IV > > we get overlapping life-ranges for the before and after value because > > that inhibits coalescing. Is this what happens here? > ... > ... > > So we indeed have p_20 and p_9 live as p_9 is used after the loop. > > Originally > > this wasn't the case but fold_stmt in the first forwprop pass does this > > by means of following use-def chains. > > I'm a bit confused. > > Where are you looking, after the forprop1 pass? Because after forwprop1 I > see: > > <bb 5> : > p_22 = p_8 + 4294967294; > MEM[(char *)p_19 + 4294967295B] = 45; > > <bb 6> : > # p_9 = PHI <p_19(4), p_22(5)> > return p_9; > > Which as I understand has: > > p_8 being the IV at the beginning of the last iteration. > p_19 being the IV at the end of the last iteration. > p_22 being the IV at the end of the last iteration MINUS 1. > > I don't see a p_20 anywhere. Did you mean that p_8 and p_19 where both live > at > the end of the loop? Yes. Not sure if that captures all of the issues in this bug but that's clearly bad.
