https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69989
--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 29 Feb 2016, law at redhat dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69989 > > --- Comment #11 from Jeffrey A. Law <law at redhat dot com> --- > The last proposal (clear LOOPS_NEED_FIXUP) is a possibility. I can poke at > that a bit, but I really wonder if it'd be better for gcc-7 and for gcc-6 if > we > should just use localized fixups rather than trying to detect in the CFG > manipulation bits. > > I think the big question here is how do we want the CFG manipulations to > interact with loop structures in the long term. Yeah, auto-fixing up loop structures from CFG hooks is difficult at best. It's some what easier for high-level ops (redirect-edge-and-branch) than from very low level ones (remove_edge, delete_basic_block). I suspect we need more highlevel workers to avoid duplicating loop fixup handling everywhere. > And it's not just edge removal that can turn an irreducible loop into a > natural > loop -- that can happen with block/edge duplication as well. True, that would be handling in redirect_edge_and_branch. I think we want to handle fixup conservatively so it works for non-loop passes and have loop passes that know they update loop structure correctly simply use checking_verify_loop_structure with clearing LOOPS_NEED_FIXUP (we should rename it then to sth like loops_need_no_fixup ()). Given that checking_verify_loop_structure asserts no fixup is necessary at the moment that's a sensible change IMHO (and the verification itself will report any actual issues if fixup would have been necessary). The other possibility is to always do a fixup in loop_optimizer_init rather than doing that lazily. I've tried to avoid this to force passes (and CFG helpers) to handle things correctly (and also to avoid the compile-time cost of course).
