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?
Martin
Richard.
Thanks,
Martin
