Hi,

On Thu, Apr 2, 2015 at 5:51 PM, James Greenhalgh
<james.greenhalgh@arm.com> wrote:
> 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).

I thought that adding flags for new processors was ok at any time,
even to backport.

> 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.

Fixed in the attached patch.

>
> +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.

Agreed.  Fixed.

I'm testing the two patches with bootstrap and make check on Juno
aarch64-linux and Arndale arm-linux.
Ok for trunk after regstrap passes?

Thanks,
Sebastian