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

[Jan Beulich <jbeulich@suse.com>]

On 02.02.2023 13:13, Tamar Christina wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Thursday, February 2, 2023 11:30 AM
>> To: Tamar Christina <Tamar.Christina@arm.com>
>> Cc: nd <nd@arm.com>; Richard Earnshaw <Richard.Earnshaw@arm.com>;
>> Marcus Shawcroft <Marcus.Shawcroft@arm.com>; binutils@sourceware.org
>> Subject: Re: [PATCH][Binutils]AArch64 gas: relax ordering constriants on
>> enabling and disabling feature extensions
>>
>> 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.
> 
> Perhaps, but this change was to address some user feedback in which determining
> the order means they have to parse what definition for an -mcpu value the compiler
> has and understand the options and re-order them to add their own extensions on top.
> 
> People do this because binutils doesn't understand -mcpu.
> 
> The compiler already doesn't care about the order,  even though for a compiler the no
> Makes more sense as it turns off code generation for a particular instruction,
> particular auto-vec and intrinsics.  For an assembler, your assembly file doesn't magically
> include instructions for things you want to disable, you have to actively do so.

Well, an assembler file can grow over time, and it may contain multiple variants
of code targeting hardware with different capabilities. There may be many
instances of directives controlling the enabled/disabled extensions. Someone
adding new code there may not pay close enough attention to feature prereqs and
mix up insn flavors (like the SIMD vs SVE variants of the I8MM example I gave),
resulting in wrong code to be produced instead of a build time error.

> Also today we
> only have this limit on instructions, registers don't get gated like this.  Those already ignore
> all extension flags. So I think the risk is much lower in reality.
> 
> But.. If it's really a concern you have I can make it a warning instead of a hard error.

Would that help the people who have asked for the change you're proposing here?
I guess if it at all then only if additionally there is a command line option
to silence that warning?

Jan