Wilco Dijkstra via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
> The --with-cpu/--with-arch configure option processing not only checks valid
> arguments
> but also sets TARGET_CPU_DEFAULT with a CPU and extension bitmask. This
> isn't used
> however since a --with-cpu is translated into a -mcpu option which is
> processed as if
> written on the command-line (so TARGET_CPU_DEFAULT is never accessed).
>
> So remove all the complex processing and bitmask, and just validate the
> option.
> Fix a bug that always reports valid architecture extensions as invalid. As a
> result
> the CPU processing in aarch64.cc can be simplified.
>
> Bootstrap OK, regress pass, OK for commit?
Although invoking ./cc1 directly only half-works with --with-arch,
it half-works well-enough that I'd still like to keep it working.
But I agree we should apply your change first, then I can follow up
with a patch to make --with-* work with ./cc1 later. (I have a version
locally and the net result is much simpler than the status quo, as well
as hopefully actually working properly.)
My main question about the patch itself is:
> + explicit_arch = selected_arch->arch;
> if (!selected_tune)
> selected_tune = selected_cpu;
> + explicit_tune_core = selected_tune->ident;
> +
> + gcc_assert (explicit_tune_core != aarch64_none);
> + gcc_assert (explicit_arch != aarch64_no_arch);
Do we still need both selected_arch and explicit_arch? explicit_arch
seems a misnomer now, since it includes implicit as well as explicit
choices. Same for selected_tune and explicit_tune_core.
aarch64_option_restore has:
if (opts->x_explicit_tune_core == aarch64_none
&& opts->x_explicit_arch != aarch64_no_arch)
selected_tune = &all_cores[selected_arch->ident];
else
selected_tune = aarch64_get_tune_cpu (ptr->x_explicit_tune_core);
Is the “if” condition ever true, or can we now restore the tune
info unconditionally?
Thanks,
Richard
