From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by sourceware.org (Postfix) with ESMTPS id 01F393858410 for ; Thu, 10 Mar 2022 12:24:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 01F393858410 Received: from dggpeml500023.china.huawei.com (unknown [172.30.72.55]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4KDp7J62KSz9sbj; Thu, 10 Mar 2022 20:20:44 +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 20:24:27 +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> <983f339f-aed8-7250-4e99-c9e77ea25b28@suse.com> From: Shaokun Zhang Message-ID: <07dba12f-d9f9-ea92-cdea-2f084d4d1116@hisilicon.com> Date: Thu, 10 Mar 2022 20:24:26 +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: <983f339f-aed8-7250-4e99-c9e77ea25b28@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: dggems701-chm.china.huawei.com (10.3.19.178) To dggpeml500023.china.huawei.com (7.185.36.114) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.9 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 12:24:33 -0000 Hi, On 2022/3/10 19:50, Jan Beulich wrote: > On 10.03.2022 12:33, Shaokun Zhang wrote: >> 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? > > Well, as for any patch a maintainer of the code needs to give you their okay. > Oh, Got it, I will loop the AARCH64 maintainers. Thanks Jan. > Jan > > . >