Re: [PATCH][AArch64][6/14] Implement TARGET_OPTION_SAVE/TARGET_OPTION_RESTORE

[James Greenhalgh <james.greenhalgh@arm.com>]

On Fri, Jul 17, 2015 at 03:19:20PM +0100, Kyrill Tkachov wrote:
> 
> 
> This is a slight respin of this patch, handling the -moverride string more gracefully.
> We need to explicitly save and restore it in TARGET_OPTION_SAVE otherwise the option gen machinery
> gets confused about its type and during its printing uses the wrong format code for the pointer, leading to a warning that may trigger during bootstrap.
> 
> Otherwise it is the same as the previous version.
> 
> Bootstrapped and tested on aarch64.
> I'd like to propose this version instead of the original.
> 
> Ok?

The ChangeLog looks outdated with respect to the patch, in particular:

>      (x_aarch64_isa_flags): Likewise.

This is just "aarch64_isa_flags" in the file.

> +TargetSave
> +const char *x_aarch64_override_tune_string
> +

This is not mentioned.

>      (master=): Likewise.

This doesn't exist.

> +#undef TARGET_OPTION_SAVE
> +#define TARGET_OPTION_SAVE aarch64_option_save
> +

This is not mentioned.

In addition to the ChangeLog nits,

> +/* Return the CPU corresponding to the enum CPU.
> +   If it doesn't specify a cpu, return the default.  */
> +
> +static const struct processor *
> +aarch64_get_tune_cpu (enum aarch64_processor cpu)
> +{
> +  if (cpu != aarch64_none)
> +    return &all_cores[cpu];
> +
> +  return &all_cores[TARGET_CPU_DEFAULT & 0x3f];
> +}

This looks strange to me, is there nothing we can do to make it clear
what "0x3f" means in this context, or better yet to get rid of the
two-in-one variable...

OK with a fixed ChangeLog.

Thanks,
James