Re: [PATCH] aarch64: allow adding/removing just feature flags via .arch

["Jan Beulich" <JBeulich at suse dot com>]

>>> On 20.10.14 at 14:27, <marcus.shawcroft@gmail.com> wrote:
> On 20 October 2014 10:23, Jan Beulich <JBeulich@suse.com> wrote:
>> Rather than requiring to always also set/change the base architecture,
>> allow that part to be omitted, making it possible to en-/disabled and
>> then dis-/enable again just certain of the architecture extensions.
> 
> I'd like to keep the behaviour of the .arch and .cpu directives in ARM
> and AArch64 backends aligned, for that reason I would prefer that we
> add the missing .arch_extension directive to the AArch64 backend, see
> the ARM backend:
> 
> @cindex @code{.arch_extension} directive, ARM
> @item .arch_extension @var{name}
> Add or remove an architecture extension to the target architecture.  Valid
> values for @var{name} are the same as those accepted as architectural
> extensions by the @option{-mcpu} commandline option.
> 
> @code{.arch_extension} may be used multiple times to add or remove 
> extensions
> incrementally to the architecture being compiled for.

I understand the desire for consistency with ARM, but before going
that route I'd like to point out that there are shortcomings with that
directive there, and a patch to eliminate those
(https://sourceware.org/ml/binutils/2013-04/msg00070.html) didn't
get accepted (in fact there never was any kind of response).
Admittedly right now there are no features setting multiple bits in
AArch64 yet, but I kind of suspect this will change over time. Hence
what I'd minimally like to know is whether at least that level of
divergence (i.e. using distinct values to enable/merge and to disable
a feature) would be acceptable, or whether to go the dual model
("no" and "no-" prefixes having different meaning) also proposed as
an alternative there.

Jan