https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125120
--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> --- > Am 04.05.2026 um 16:21 schrieb amacleod at redhat dot com > <[email protected]>: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125120 > > --- Comment #3 from Andrew Macleod <amacleod at redhat dot com> --- > (In reply to Richard Biener from comment #2) >> unreachable() should be gone before loop opts, not sure why that doesn't >> happen. LIM isn't hindered by multi-exits in principle, but we restrict >> store motion >> of conditionally executed stores - because we have to emit a load in the >> preheader. We could possibly do flag-based SM to avoid this (but usually >> not a good idea due to cost). >> >> Hmm, but indeed, we seem to remove __builtin_unreachable () from the 2nd >> VRP pass only. Why's that so? We did it very much earlier in the past. > > > We can only remove it if we can safely update global values to reflect the > conditional knowledge everywhere it is used. > > It will always be removed by VRP2 now, but it will be removed earlier if it > can > be proven safe to do so. I think it has always been this way. > > I went back to GCC11, and : > void foo (void); > > int > f (int i, int j) > { > if (j == 1) > { > if (i > 1) > __builtin_unreachable(); > if (i > 1) > foo (); > } > if (i == 2) > foo (); > return i == 0; > } > > Allows __builtin_unreachable to go past vrp2 by a few passes before it is just > dropped. I see. For the purpose of vectorization we could elide exits to unreachable during if-conversion for vectorization. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
