From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by sourceware.org (Postfix) with ESMTPS id 97ADA3857C67 for ; Thu, 10 Mar 2022 11:33:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 97ADA3857C67 Received: from dggpeml500023.china.huawei.com (unknown [172.30.72.53]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4KDn2n6Z3PzBrlG; Thu, 10 Mar 2022 19:31:45 +0800 (CST) Received: from [10.67.77.175] (10.67.77.175) by dggpeml500023.china.huawei.com (7.185.36.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 10 Mar 2022 19:33:42 +0800 Subject: Re: [PATCH RESEND v2] Aarch64: Allow explicit size specifier for predicate operand of {sq, uq, }{incp, decp} To: Jan Beulich CC: Jingtao Cai , Bo Dong , References: <20220216005311.26184-1-zhangshaokun@hisilicon.com> <7435dbfd-5b5d-60d0-7376-83c209c77541@suse.com> <91de3faa-b7b5-07ae-37ef-0eb996bc340a@hisilicon.com> <99db07d9-ad39-86a7-727d-be0edce7ab19@suse.com> From: Shaokun Zhang Message-ID: Date: Thu, 10 Mar 2022 19:33:41 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <99db07d9-ad39-86a7-727d-be0edce7ab19@suse.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.77.175] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggpeml500023.china.huawei.com (7.185.36.114) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2022 11:33:46 -0000 Hi Jan, On 2022/3/10 18:38, Jan Beulich wrote: > On 10.03.2022 10:38, Shaokun Zhang wrote: >> Hi Jan, > > Despite this, ... > >> On 2022/3/2 15:36, Shaokun Zhang wrote: >>> On 2022/2/21 21:13, Jan Beulich wrote: >>>> On 16.02.2022 01:53, Shaokun Zhang wrote: >>>>> --- a/gas/testsuite/gas/aarch64/sve-movprfx_23.d >>>>> +++ b/gas/testsuite/gas/aarch64/sve-movprfx_23.d >>>>> @@ -9,29 +9,29 @@ Disassembly of section .*: >>>>> >>>>> 0+ <.*>: >>>>> [^:]+: 04512461 movprfx z1.h, p1/m, z3.h >>>>> -[^:]+: 256c8021 incp z1.h, p1 // note: merging predicate expected due to preceding `movprfx' at operand 2 >>>>> +[^:]+: 256c8021 incp z1.h, p1.h // note: merging predicate expected due to preceding `movprfx' at operand 2 >>>> >>>> I have a more general question here: Couldn't the spec make optional the >>>> use of all the same size specifiers when there are multiple, same element >>>> size operands? One such suffix of course needs to be there to disambiguate >>> >>> We are not from ARM SPEC group and don't know the exact considerations for >>> the forbidden omitting suffix. We guess people will have different answers from >>> different points of view. >>> >>> >From our point of view, a suffix makes the assembly more consistent with the >>> scalar versions of `incp`, e.g. `incp x1, p2.b`. And the predicate register acts more >>> like a vector register within this instruction, with suffix, the addend for each element >>> is clear once reading the assembly string. >>> >>> Not sure that anyone from ARM in the mail-list can give more hints or thoughts. >>> >> >> No any more comments from Arm guys. >> >> Is it ok for trunk? > > ... I assume you understand that I'm not in the position to give you the > wanted "okay"? Apologies that I don't follow it completely, do you mean that does it need someone to agree and take it? Or we need more comments? Thanks, Shaokun > > Jan > > . >