From: "Martin Liška" <mliska@suse.cz>
To: Richard Biener <richard.guenther@gmail.com>
Cc: "Joseph S. Myers" <joseph@codesourcery.com>,
GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Fix handling of flag_rename_registers.
Date: Wed, 13 Oct 2021 12:02:22 +0200 [thread overview]
Message-ID: <a1b59126-3774-6d61-1032-182a7ee67a62@suse.cz> (raw)
In-Reply-To: <CAFiYyc28d3=MmtPHXONcL2L5H654Onkgt8+6gJyA_Vkr8TV8dg@mail.gmail.com>
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?
Martin
>
> Richard.
>
>> Thanks,
>> Martin
next prev parent reply other threads:[~2021-10-13 10:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-12 12:17 Martin Liška
2021-10-12 13:37 ` Richard Biener
2021-10-12 14:03 ` Martin Liška
2021-10-12 15:11 ` Martin Liška
2021-10-13 8:39 ` Richard Biener
2021-10-13 10:02 ` Martin Liška [this message]
2021-10-13 11:49 ` Richard Biener
2021-10-14 14:27 ` Jeff Law
2021-10-15 15:27 ` Martin Liška
2021-10-16 19:51 ` Jeff Law
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a1b59126-3774-6d61-1032-182a7ee67a62@suse.cz \
--to=mliska@suse.cz \
--cc=gcc-patches@gcc.gnu.org \
--cc=joseph@codesourcery.com \
--cc=richard.guenther@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).