On Wed, Oct 13, 2021 at 12:02 PM Martin Liška <mli...@suse.cz> wrote: > > On 10/13/21 10:39, Richard Biener wrote: > > On Tue, Oct 12, 2021 at 5:11 PM Martin Liška <mli...@suse.cz> wrote: > >> > >> On 10/12/21 15:37, Richard Biener wrote: > >>> by adding EnabledBy(funroll-loops) to the respective options instead > >>> (and funroll-loops EnabledBy(funroll-all-loops)) > >> > >> All right, so the suggested approach works correctly. > >> > >> Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > >> > >> Ready to be installed? > > > > funroll-all-loops > > -Common Var(flag_unroll_all_loops) Optimization > > +Common Var(flag_unroll_all_loops) Optimization EnabledBy(funroll-all-loops) > > > > that should be on funroll-loops? > > Yeah, what a stupid error. > > > > > Can you verify that the two-step -funroll-all-loops -> -funroll-loops > > -> -frename-registers > > Yes, verified that in debugger, it's not dependent on an ordering. > > > works and that it is not somehow dependent on ordering? Otherwise we have > > to > > use EnabledBy(funroll-loops,funroll-all-loops) on frename-registers. > > I guess the > > EnabledBy doesn't work if the target decides to set flag_unroll_loop in one > > of > > its hooks rather than via its option table override? (as said, this > > is all a mess...) > > It's a complete mess. The only override happens in > rs6000_override_options_after_change. I think it can also utilize EnabledBy, > but > I would like to do it in a different patch. > > > > > But grep should be your friend telling whether any target overrides > > any of the flags... > > > > I do hope we can eventually reduce the number of > > pre-/post-/lang/target/common > > processing phases for options :/ Meh. > > Huh. > > May I install this fixed patch once it's tested?
Yes please. Thanks, Richard. > Martin > > > > > Richard. > > > >> Thanks, > >> Martin >
