This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][AArch64] Enable -frename-registers at -O2 and higher
- From: James Greenhalgh <james dot greenhalgh at arm dot com>
- To: Kyrill Tkachov <kyrylo dot tkachov at foss dot arm dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Marcus Shawcroft <marcus dot shawcroft at arm dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, <nd at arm dot com>, <philipp dot tomsich at theobroma-systems dot com>, <pinskia at gmail dot com>, <jim dot wilson at linaro dot org>, <benedikt dot huber at theobroma-systems dot com>, "Evandro Menezes" <e dot menezes at samsung dot com>, Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- Date: Tue, 31 May 2016 10:56:40 +0100
- Subject: Re: [PATCH][AArch64] Enable -frename-registers at -O2 and higher
- Authentication-results: sourceware.org; auth=none
- Nodisclaimer: True
- References: <57485097 dot 4040704 at foss dot arm dot com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:23
On Fri, May 27, 2016 at 02:50:15PM +0100, Kyrill Tkachov wrote:
> Hi all,
>
> As mentioned in https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00297.html,
> frename-registers registers can be beneficial for aarch64 and the patch at
> https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01618.html resolves the
> AESE/AESMC fusion issue that it exposed in the aarch64 backend. So this patch
> enables the pass for aarch64 at -O2 and above.
>
> Bootstrapped and tested on aarch64-none-linux-gnu.
>
> Ok for trunk?
Not without some more detail on the situations in which this is a likely
gain for AArch64 and whether this expected improvement is generic enough
to enable it for all AArch64 targets and worth the compile time trade-off.
As you're proposing to have this on by default, I'd like to give a chance
to hear whether there is consensus as to this being the right choice for
the thunderx, xgene1, exynos-m1 and qdf24xx subtargets.
My expectation is that the slight code size decrease is likely to be a good
thing everywhere, and the breaking of register dependency chains may give
better scheduling for our cores with detailed scheduling models. So we're
unlikely to cause any performance worries, and may get a slight uplift in
a few places. Any data confirming that would be useful. I'd also like to see
some estimates for the impact on compilation time (we are already running
one regrename pass when targeting Cortex-A57).
If we can't reach consensus, then the next best approach is to add this as
a new option to AARCH64_EXTRA_TUNING_OPTION and enable it as appropriate
for subtargets - you might find that this is not worthwhile for the small
uplift Ramana and Wilco measured.
I've widened the CC list for you, let's wait a week for comments and make
a decision then.
Thanks,
James
> P.S. Why is the table holding this information called aarch_option_optimization_table rather than
> aarch64_option_optimization_table ?
>
> 2016-05-27 Kyrylo Tkachov <kyrylo.tkachov@arm.com>
>
> * common/config/aarch64/aarch64-common.c
> (aarch64_option_optimization_table): Enable -frename-registers at
> -O2 and higher.
> diff --git a/gcc/common/config/aarch64/aarch64-common.c b/gcc/common/config/aarch64/aarch64-common.c
> index 08e795934207d015d9fa22c3822930af4a21c93a..91801df731471f1842802370497e498fda62098a 100644
> --- a/gcc/common/config/aarch64/aarch64-common.c
> +++ b/gcc/common/config/aarch64/aarch64-common.c
> @@ -50,6 +50,8 @@ static const struct default_options aarch_option_optimization_table[] =
> { OPT_LEVELS_1_PLUS, OPT_fsched_pressure, NULL, 1 },
> /* Enable redundant extension instructions removal at -O2 and higher. */
> { OPT_LEVELS_2_PLUS, OPT_free, NULL, 1 },
> + /* Enable the register renaming pass at -O2 and higher. */
> + { OPT_LEVELS_2_PLUS, OPT_frename_registers, NULL, 1 },
> { OPT_LEVELS_NONE, 0, NULL, 0 }
> };
>