[PATCH]AArch64 gas: relax ordering constriants on enabling and disabling feature extensions

[Richard Sandiford]

Jan Beulich via Binutils <binutils@sourceware.org> writes:
> On 01.02.2023 20:25, Tamar Christina via Binutils wrote:
>> At the beginning of the port it was decided that enabling features should always
>> come before disabling features. i.e. +foo should always be before any +nofoo.
>> 
>> For years now this has been relaxed in GCC but binutils has remained rather
>> strict.  This removes the restriction from gas as well giving users less
>> friction.
>
> Hmm, specifying negative before positive settings may mean the negative ones
> don't take effect at all (because of feature dependencies). While the same
> of course is true the other way around as well, silently accepting
> supposedly disabled insns is imo quite a bit more risky than complaining
> about supposedly enabled ones: The programmer may unknowingly produce a bad
> binary. This is even more so that the dependencies can't be considered set
> in stone - bugs may be found which require adjustments to them.

Like you say, if we allow positive and negative options to be specified
at the same time, there's no structural way of avoiding the risk that
one option will fully override the other.  But that's true of many other
aspects of command-line option handling too, especially in GCC.

I don't think there's any push to prevent positive and negative options
from being used together in all circumstances.  It's just a question
of degree.  But when deciding that degree, there is (IMO) no good reason
for GCC to be more lenient than GAS, or GAS to be more strict than GCC.
Whatever risks there are are broadly the same for both.  For example,
any mistake that a programmer can make directly in assembly, they can
also make in inline asm.  And as things stand, GCC will accept
negative-before-positive features and emit a conforming .arch, which
already allows inline asm programmers to fall into whatever traps the
patch would open up for direct use of GAS.  I haven't heard of any
instances of that causing problems in practice.

There's also the question of whether people writing directly in assembly
need to be protected more than people writing in intrinsics.  Personally
I think it's the opposite: the assembler is the lowest-level coding tool
we provide, and it should trust the user as much as possible.

> There actually is an example of something which may want adjusting: Both
> F32MM and F64MM take SVE as prereq. While SVE can't easily be a prereq to
> I8MM (because there are also SIMD insn forms), it's unclear why SIMD
> - itself being a prereq to SVE - isn't a prereq to I8MM.

Good spot!  That looks like a bug.  In the corresponding GCC logic,
+i8mm does imply +simd, which like you say seems like the correct
behaviour.

Thanks,
Richard