On Mon, 25 Feb 2013, Steven Bosscher wrote: > On Mon, Feb 25, 2013 at 8:53 PM, Marek Polacek wrote: > > This fixes PR56426. We were ICEing during the loop pipeline, > > because copyprop changed an irreducible region into a reducible - thus > > the number_of_loops grew. > > We've seen that kind of thing happen before with the tracer pass. It > makes me worried a bit about the robustness of preserving loops... > > Is there anything in the loop maintenance frame work that catches and > handles new loops if they are "spontaneously" created from previously > irreducible regions?
Yes, I very recently have re-written fix_loop_structure to take care of discovering new loops (via making flow_loops_find work incremental ontop of an existing loop tree). The only drawback is that it is now too easy to not "preserve" loops (that is, keep their number and struct loop the same) by first dropping it and then re-discover it via fix_loop_structure. At least dump files now contain both loop nodes that are removed and loop nodes that are newly discovered. Richard.
