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

[Jan Beulich]

On 02.02.2023 14:21, Richard Sandiford wrote:
> 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.

I don't agree here (if anything, I'd expect the compiler to be more strict),
but I realize that via a sequence of .arch_extension directives the same
situation could arise. Hence I guess there's no real reason to not also be
more relaxed in the parsing here.

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

I'll make a patch then.

Jan