From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by sourceware.org (Postfix) with ESMTPS id 0F5513858C83 for ; Thu, 10 Mar 2022 09:38:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0F5513858C83 Received: from dggpeml500023.china.huawei.com (unknown [172.30.72.54]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4KDkQz4byDzcb1Q; Thu, 10 Mar 2022 17:34:03 +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 17:38:53 +0800 Subject: Re: [PATCH RESEND v2] Aarch64: Allow explicit size specifier for predicate operand of {sq, uq, }{incp, decp} From: Shaokun Zhang To: Jan Beulich CC: Jingtao Cai , Bo Dong , References: <20220216005311.26184-1-zhangshaokun@hisilicon.com> <7435dbfd-5b5d-60d0-7376-83c209c77541@suse.com> Message-ID: <91de3faa-b7b5-07ae-37ef-0eb996bc340a@hisilicon.com> Date: Thu, 10 Mar 2022 17:38:53 +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: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.77.175] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) 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 09:38:59 -0000 Hi Jan, On 2022/3/2 15:36, Shaokun Zhang wrote: > Hi Jan, > > 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? Thanks, Shaokun > Cheers, > > >> different element size forms of the same insn, but the redundancy merely >> adds clutter imo. >> >> Jan >> >> . >>