This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] [ARM] Add support for the Samsung Exynos M1 processor
- From: James Greenhalgh <james dot greenhalgh at arm dot com>
- To: Sebastian Pop <sebpop at gmail dot com>
- Cc: Evandro Menezes <e dot menezes at samsung dot com>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>, Kyrylo Tkachov <Kyrylo dot Tkachov at arm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 2 Apr 2015 23:51:06 +0100
- Subject: Re: [PATCH] [ARM] Add support for the Samsung Exynos M1 processor
- Authentication-results: sourceware.org; auth=none
- References: <055b01d06b33$bdcce3d0$3966ab70$ at samsung dot com> <551A5BCA dot 1030203 at arm dot com> <003601d06c13$203447e0$609cd7a0$ at samsung dot com> <CAFk3UF-G-O2E2+RcBix8DCZ1rvK3J6wHAWUU8R5FMo2_NK=O_A at mail dot gmail dot com>
On Thu, Apr 02, 2015 at 11:19:14PM +0100, Sebastian Pop wrote:
> Hi,
>
> from what I understand, Evandro has addressed the comments from Kyrill.
> Are there other problems to be addressed before the patches can go in?
Trunk is currently in Stage 4 development, these patches are fairly
low-risk, but they are certainly not regression fixes. I'll defer
to port maintainers and release managers for the final say, but in my
opinion it would not be appropriate to commit them until Stage 1
development for GCC 6.0 opens (hopefully in a few weeks).
For the AArch64 patch, I was expecting to see a respin after Junmo's
comment on Wednesday [1].
In particular:
+AARCH64_CORE("exynos-m1", exynosm1, exynosm1, 8, AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, exynosm1)
As there has not been a scheduling model contributed for the exynos-m1,
this will use *no* scheduling model on AArch64. This is unlikely to give
good performance.
+static const struct tune_params exynosm1_tunings =
+{
+ &cortexa57_extra_costs,
+ &cortexa57_addrcost_table,
+ &cortexa57_regmove_cost,
+ &cortexa57_vector_cost,
+ 4, /* memmov_cost */
+ 3, /* issue_rate */
+ (AARCH64_FUSE_MOV_MOVK | AARCH64_FUSE_ADRP_ADD
+ | AARCH64_FUSE_MOVK_MOVK), /* fuseable_ops */
+ 16, /* function_align. */
+ 8, /* jump_align. */
+ 4, /* loop_align. */
+ 2, /* int_reassoc_width. */
+ 4, /* fp_reassoc_width. */
+ 1 /* vec_reassoc_width. */
+};
+
As these are identical to the Cortex-A57 tuning, is there any reason to
add them? I'd prefer if we took a copy-on-modify policy for these
tuning structs, only adding them where there is a difference.
Thanks,
James
---
[1]: https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00001.html