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 CBEB43858C5E for ; Mon, 3 Apr 2023 08:27:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CBEB43858C5E 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 1009D1063; Mon, 3 Apr 2023 01:28:08 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 21A313F6C4; Mon, 3 Apr 2023 01:27:23 -0700 (PDT) From: Richard Sandiford To: Jan Beulich Mail-Followup-To: Jan Beulich ,binutils@sourceware.org, richard.sandiford@arm.com Cc: binutils@sourceware.org Subject: Re: [PATCH 00/31] aarch64: Add SME2 support References: <20230330102646.3327818-1-richard.sandiford@arm.com> Date: Mon, 03 Apr 2023 09:27:21 +0100 In-Reply-To: (Jan Beulich's message of "Mon, 3 Apr 2023 10:14:39 +0200") 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=-25.5 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 writes: > On 03.04.2023 10:05, Richard Sandiford wrote: >> Jan Beulich writes: >>> On 30.03.2023 12:26, Richard Sandiford via Binutils wrote: >>>> Richard Sandiford (31): >>>> aarch64: Add +sme2 >>>> aarch64: Add a _10 suffix to FLD_imm3 >>>> aarch64: Add _off4 suffix to AARCH64_OPND_SME_ZA_array >>>> aarch64: Add support for vgx2 and vgx4 >>>> aarch64; Add support for vector offset ranges >>>> aarch64: Add support for predicate-as-counter registers >>>> aarch64: Add the SME2 MOVA instructions >>>> aarch64: Add the SME2 multivector LD1 and ST1 instructions >>> >>> Less than a 3rd of the patches in this series have made it to my mailbox >>> (and the list archives), so commenting on e.g. the one above is difficult. >> >> Yeah, they got held up in moderation due to the size. >> >>> Nevertheless - according to the documentation LD1x (scalar plus immediate, >>> consecutive registers) and their LDNT1x, ST1x, and STNT1x counterparts >>> are (unlike the strided forms) SVE2.1 insns, not SME2 ones (IOW it looks >>> as if the use of SME2_INSN() there is wrong, unless the documentation is >>> categorizing these incorrectly). >> >> They're both (but we haven't added SVE2p1 to binutils yet). >> E.g. see the pseudocode in: >> >> https://developer.arm.com/documentation/ddi0602/2022-12/SVE-Instructions/LD1B--scalar-plus-immediate--consecutive-registers---Contiguous-load-of-bytes-to-multiple-consecutive-vectors--immediate-index--?lang=en >> >> where the condition is: >> >> if !HaveSME2() && !HaveSVE2p1() then UNDEFINED; >> >> Chronologically, SME2 predates SVE2p1. > > Yet aiui dependency-wise, like SVE2 is a prereq to SME, SVE2.1 is going > to be viewed as a prereq to SVE2.1? Do you mean SVE2p1 being a prereq to SME2? If so, no. FEAT_SME2 && !FEAT_SVE2p1 is a valid combination, and in that case, these instructions will only be available in streaming mode. The way the pseudo expresses this is: if HaveSVE2p1() then CheckSVEEnabled(); else CheckStreamingSVEEnabled(); > In which case enabling SVE2.1 alone > ought to be sufficient to use these insns? Which would mean all of these > (there are quite a few more) would need touching again. When SVE2p1 is added, we'll need to make these instructions available whenever SVE2p1 or SME2 is enabled. It didn't seem worth preempting that by adding SVE2p1 stuff in this series, not least because it wouldn't be testable. But it should be a simple enough change. Thanks, Richard