Re: [PATCH] Fix handling of flag_rename_registers.

[Richard Biener <richard.guenther@gmail.com>]

On Wed, Oct 13, 2021 at 12:02 PM Martin Liška <mliska@suse.cz> wrote:
>
> On 10/13/21 10:39, Richard Biener wrote:
> > On Tue, Oct 12, 2021 at 5:11 PM Martin Liška <mliska@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
>