https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123801
--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Siddhesh Poyarekar from comment #9) > (In reply to Richard Biener from comment #8) > > Doing it on-demand, aka only when VN figures a problematic equivalency is > > difficult. Doing it generally, like for example during laddress, will wreck > > all those testcases Martin added ... doing it semi-on-demand, like only when > > VN substitutes a SSA name for a constant address would be possible, but it > > will miss _1 = &a[i_2]->a.b.c; vs. _3 = &a[i_2]->a.c.d; which is way more > > ugly to handle (we'd have to rewrite the prevailing definition which we'd > > not touch otherwise, only when there are going to be additional uses). > > AFAICT, the only conflicting equivalency is when an address to a larger > object is replaced with an address to a smaller object; would that be too > expensive to avoid? Avoiding the CSE? No, we already do that early. Working around by turning the CSEd address into sth no longer exposing the explicit subobject access? Yes. That's not easily posible (it's also not just VN). Also ... > > IMO the late diagnostic passes should be all moved, at least to before loop > > optimizations (or laddress). > > That has it's own problems, from warnings on dead code (like I fixed by > disabling much of waccess2) to missing a bunch of actual issues. ... there's a catch-22 where such equivalences often allow dead code to be removed in the first place, so avoiding CSE will lead to more bogus diagnostics. As Jakub said, the issue of diagnostics on unreachable code should be addressed by other means. Queuing the diagnostics based on location and only emitting them if any stmt with that location is emitted in the end would be another, possibly less invasive (and prone to code generation differences) approach. It might need extensive use of discriminators as diagnostics are often emitted on specific copies of code.
