From: Jan Beulich <jbeulich@suse.com>
To: richard.sandiford@arm.com, Tamar Christina <tamar.christina@arm.com>
Cc: nd@arm.com, Binutils <binutils@sourceware.org>,
Richard.Earnshaw@arm.com, marcus.shawcroft@arm.com
Subject: Re: [PATCH]AArch64 gas: relax ordering constriants on enabling and disabling feature extensions
Date: Fri, 3 Feb 2023 08:13:22 +0100 [thread overview]
Message-ID: <61c5de75-d2c9-0e1b-0a4b-f5ba152f8510@suse.com> (raw)
In-Reply-To: <mpty1pgcif6.fsf@arm.com>
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
prev parent reply other threads:[~2023-02-03 7:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-01 19:25 [PATCH][Binutils]AArch64 " Tamar Christina
2023-02-02 11:29 ` Jan Beulich
2023-02-02 12:13 ` Tamar Christina
2023-02-02 12:25 ` Jan Beulich
2023-02-02 13:21 ` [PATCH]AArch64 " Richard Sandiford
2023-02-03 7:13 ` Jan Beulich [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=61c5de75-d2c9-0e1b-0a4b-f5ba152f8510@suse.com \
--to=jbeulich@suse.com \
--cc=Richard.Earnshaw@arm.com \
--cc=binutils@sourceware.org \
--cc=marcus.shawcroft@arm.com \
--cc=nd@arm.com \
--cc=richard.sandiford@arm.com \
--cc=tamar.christina@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).