https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66142
--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> --- As said in comment #9, this is PR63916 I think. We have _9 = &D.3665[_11].org; MEM[(struct vec_ *)_9] = 1.0e+0; MEM[(struct vec_ *)_9 + 4B] = _8; ... _24 = MEM[(const struct Ray *)&D.3665][_11].org.x; _27 = MEM[(const struct Ray *)&D.3665][_11].org.y; which ultimately is from inlining of D.3665[D.3663].org = p; D.3665[D.3663].dir.x = x; D.3665[D.3663].dir.y = y; D.3664[D.3663].t = 1.0e+10; D.3664[D.3663].h = 0; D.3667 = &D.3665[D.3663]; D.3668 = &D.3664[D.3663]; bar (D.3668, D.3667, &spheres[0]); to p.x = 1.0e+0; p.y = _9; ... D.3665[_15].org = p; D.3665[_15].dir.x = x_16; D.3665[_15].dir.y = y_17; D.3664[_15].t = 1.0e+10; D.3664[_15].h = 0; _23 = &D.3665[_15]; _24 = &D.3664[_15]; _32 = MEM[(const struct Ray *)_23].org.x; forwprop cannot forward &D.3665[_15] into the dereference (it would create a bogus access paths even if types were matching and TBAA would be fine). And SCCVN isn't able to "canonicalize" the accesses (because it doesn't look at stmt defs when building the canonical address of an access). Note that PRE uses the canonical form for expression insertion so we have to be careful what we put in the canonical form (or separate the address compute from the actual dereference). Yes, lowering the access more in the SCCVN machinery would be possible (say, use the affine combination machinery with the powers of affine-comb-expand (and making that use the VN lattice...)), but the issue with this is always PRE insertion and us _not_ wanting to have all PRE inserted loads be fully lowered to address-compute plus indirection. I hope to get to PR63916 this stage1.
