https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Robin Dapp from comment #6) > This one is really a bit tricky. > > We have the following situation: > > loop: > <bb 3> > # vectp_g.178_1078 = PHI <vectp_g.178_1079(3), &gD.2750(2)> > _911 = &MEM... vectp_g.178_1078 > MASK_LEN_LOAD (_911, ...); > vectp_g.178_1079 = vectp_g.178_1078 + 16; > goto loop; > > <bb 4>: > MASK_LEN_LOAD (_911, ...); > > During expand we basically convert back the _911 to vectp_g.178_1078 > (reverting what we did in ivopts before). Because _911 camouflages > vectp_g.178_1078 until expand we evaded the conflict checks of outof-ssa > that would catch a similar, non-camouflaged situation like: > > # vectp_g.178_1078 = PHI <vectp_g.178_1079(3), &gD.2750(2)> > MASK_LEN_LOAD (MEM... vectp_g.178_1078, ...); > vectp_g.178_1079 = vectp_g.178_1078 + 16; > goto loop; > MASK_LEN_LOAD (MEM... vectp_g.178_1078, ...); > > and would insert a copy of the definition right before the backedge. The > MASK_LEN_LOAD after the loop would then use that copy. By using _911 > instead of the original pointer no conflict is detected and we wrongly use > the incremented pointer. Without the ivopt change for TARGET_MEM_REF So you say we coalesce _1079 and _1078 but then apply TER to _911 which makes that coalescing invalid because now their lifetimes overlap? There must be some mechanisms to avoid this kind of situation so I do wonder whether it's not TER but some invalid SSA def stmt lookup that is happening upon expansion _not_ honoring the TER constaints here? That is, how do we exactly put the definition of _911 into the uses? Can you attach the RTL expansion dump?
