> -----Original Message----- > From: Richard Biener [mailto:richard.guent...@gmail.com] > Sent: 11 March 2014 10:52 > To: Paulo Matos > Cc: gcc@gcc.gnu.org > Subject: Re: dom requires PROP_loops > > On Mon, Mar 10, 2014 at 12:57 PM, Paulo Matos <pma...@broadcom.com> wrote: > > Hello, > > > > In an attempt to test some optimization I destroyed the loop property in > pass_tree_loop_done and reinstated it in pass_rtl_loop_init, however then I > noticed that pass_dominator started generating wrong code. > > My guess is that we should mark pass_dominator with PROP_loops as a required > property? Do you agree? > > No, "PROP_loops" is something artificial. Passes needing loops > will compute them (call loop_optimizer_init). > > You probably did sth wrong with how you "destroy" PROP_loops. >
Haven't done anything out of the ordinary. I actually copied what other passes do: cfun->curr_properties &= ~PROP_loops; before calling loop_optimizer_finalize. I find it strange that you actually need to do this since something like this should be done automatically if you mark the property as being destroyed. The background of my investigation in to this is that we don't like instructions in loop latches. This blocks generation of zero-overhead loops for us. PROP_loops is enabled from tree loopinit to rtl loop_done2 and with this property enabled cfg_cleanup doesn't remove empty latches allowing GCC to move instructions into the latch in the meantime. If I destroy this property (as above) in tree_ssa_loop_done and recreate it in rtl loop_init we have major performance boost because CFG cleanup removes empty loop latches but I found a case when jump threading generates wrong code in this case. > Richard.
