From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 6AE113858C60 for ; Thu, 2 Feb 2023 13:21:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6AE113858C60 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3F140C14; Thu, 2 Feb 2023 05:21:46 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.99.50]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2AF8A3F64C; Thu, 2 Feb 2023 05:21:03 -0800 (PST) From: Richard Sandiford To: Jan Beulich via Binutils Mail-Followup-To: Jan Beulich via Binutils ,Tamar Christina , Jan Beulich , nd@arm.com, Richard.Earnshaw@arm.com, marcus.shawcroft@arm.com, richard.sandiford@arm.com Cc: Tamar Christina , Jan Beulich , nd@arm.com, Richard.Earnshaw@arm.com, marcus.shawcroft@arm.com Subject: Re: [PATCH]AArch64 gas: relax ordering constriants on enabling and disabling feature extensions References: <7c6e61f4-b61c-a451-ba13-914c2e7f0dcf@suse.com> Date: Thu, 02 Feb 2023 13:21:01 +0000 In-Reply-To: <7c6e61f4-b61c-a451-ba13-914c2e7f0dcf@suse.com> (Jan Beulich via Binutils's message of "Thu, 2 Feb 2023 12:29:49 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-30.2 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Jan Beulich via Binutils 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