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 E2C513858CDA for ; Mon, 20 May 2024 13:34:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E2C513858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E2C513858CDA Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1716212097; cv=none; b=EVWWslBPq91IAxXRjpCxYZpgYDDtQKB+UJCCn/pqbj74OXKoaXWh+Yuqa7Xt1D5Yk5sRF6zHF3TcuKY8HpNlTlqQCiDja+lGSsZj2HdvmZABbYUrGCuR7tR4JbdWacaXAO0tCx4Wf8uZaRwIvm8oFYKWCqXr/xZfyKb7ttpUglM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1716212097; c=relaxed/simple; bh=K5+nnS5LAvqLw5CaIS+iiO3C0+K+LjdDS5nvA4phPJw=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=P/bQQoEPfTd5LrAXBbIGEe1KMoiKi/cLDnoDthJqbxOwoLiyrTzgjwBRc5LDYPUY+l3W2WNpIc4/Nh6KvpgNpClfSt74ENJnIML8LaWJGYgw84uKgJP/gdUmkDWv8YvyQGuv5lbXVZlKU2P//kv6nuwbB/n9f+PbVCj/qhkVdRY= ARC-Authentication-Results: i=1; server2.sourceware.org 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 A3226DA7; Mon, 20 May 2024 06:35:19 -0700 (PDT) Received: from [10.2.78.57] (e120077-lin.cambridge.arm.com [10.2.78.57]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 39E013F641; Mon, 20 May 2024 06:34:55 -0700 (PDT) Message-ID: <53375b51-1462-4743-b24b-deb9015a0ac0@arm.com> Date: Mon, 20 May 2024 14:34:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/2] gas, aarch64: Add SVE2 lut extension To: Saurabh Jha , binutils@sourceware.org References: Content-Language: en-GB From: "Richard Earnshaw (lists)" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3491.3 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: On 16/05/2024 11:37, Saurabh Jha wrote: > Introduces instructions for the SVE2 lut extension for AArch64. They are documented in the following links: > * luti2: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions/LUTI2--Lookup-table-read-with-2-bit-indices-?lang=en > * luti4: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions/LUTI4--Lookup-table-read-with-4-bit-indices-?lang=en > > These instructions use new SVE2 vector operands. They are called > SVE_Zm1_23_INDEX, SVE_Zm2_22_INDEX, and Zm3_12_INDEX and they have > 1 bit, 2 bit, and 3 bit indices respectively. > > For these new operands, we defined a new inserter and a new extractor. > > The lsb and width of these new operands are the same as many existing > operands but the convention is to give different names to fields that > serve different purpose so we introduced new fields in aarch64-opc.c > and aarch64-opc.h. > > We made a design choice for the second operand of the halfword variant of > luti4 with two register tables. We could have either defined a new operand, > like SVE_Znx2, or we could have use the existing operand SVE_ZnxN. With > the new operand, we would need to implement constraints on register > lists based on either operand or opcode flag. With existing operand, we > could just existing constraint checks using opcode flag. We chose > the second approach and went with SVE_ZnxN and added opcode flag to > enforce lengths of vector register list operands. This way, we can reuse > the existing constraint check logic. > --- > Hi, > > Regression tested for aarch64-none-elf and found no regressions. > > Ok for binutils-master? I don't have commit access so can someone please commit on my behalf? > > Regards, > Saurabh Similar comments as for patch 1/2, but additionally: + 28: 45e0b800 luti2 z0.h, \{z0.h\}, z0\[7\] The immediate field for the '[7]' index is split over two locations in the encoded pattern, so I think it's worth some additional checks here that the field is encoded in the right way. I'd suggest adding '[1]' and '[4]' variants. + 68: 4520b7c0 luti4 z0.h, \{z30.h-z31.h\}, z0\[0\] We should probably also check the wrap-around case of '{z31.h, z0.h}' Otherwise this looks OK. R.