From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) by sourceware.org (Postfix) with ESMTPS id 19B603858CDB for ; Thu, 18 Aug 2022 14:47:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 19B603858CDB Received: by mail-qt1-x82a.google.com with SMTP id s11so1254598qtx.6 for ; Thu, 18 Aug 2022 07:47:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=vYrpAia0tieDS5MORNDOZTiU9BH/kiElg6YRTz08Dzg=; b=6RGEt2VZfv9MEacTBv/hd6pNXWlsOMhMdKmDnc9F1/uHFy31md9OYg/tcg1eJhn2NP cUkqZzKmeFoeSrChHB6jILFIj+62LmztdS7DIOnwQjdGG97ko9lnVDwhdZjCitrenP0L yPuP+wPn1seNJKOzln8Sl7VZfnrrzNn0BFvruj28TH8+QHooH94oGlu14xae5XiuLW4i ttwOUPmb4J6WMBDO6O711l4STCRZdTEUoWDXltVjPCoXaEzq2lASK9PEHwnmmi/K0qfh uQdkUphQ5nneULiQQXI6IMnv0xtv6RJVIkfh933WwgieUEjSNM5wZJPeziWZcBy7OiZo aXlA== X-Gm-Message-State: ACgBeo3eg0wLnAs64kh6OMQV+XPfDFQO3505cyoVGlB5KXCV5ffLAvBu AZQCvKbagMgmWLDHaGrApA+f3YayUQM92QkpyXWHMyGW X-Google-Smtp-Source: AA6agR7iGJs5Mp48NyD1716xLJ0lPhjAqL+5sDLAim5mjDal7yLEns4CQJSgAh2K4BtvboolMeQZX7Cn8/bdOAlUHUc= X-Received: by 2002:ac8:7d13:0:b0:343:33d:f03a with SMTP id g19-20020ac87d13000000b00343033df03amr2907753qtb.500.1660834032393; Thu, 18 Aug 2022 07:47:12 -0700 (PDT) MIME-Version: 1.0 References: <32216291-fd1f-4579-87de-d24cb7190894@suse.com> In-Reply-To: From: "H.J. Lu" Date: Thu, 18 Aug 2022 07:46:36 -0700 Message-ID: Subject: Re: [PATCH 1/7] x86/Intel: restrict suffix derivation To: Jan Beulich Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3018.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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, 18 Aug 2022 14:47:14 -0000 On Wed, Aug 17, 2022 at 11:08 PM Jan Beulich wrote: > > On 17.08.2022 21:19, H.J. Lu wrote: > > On Tue, Aug 16, 2022 at 12:30 AM Jan Beulich wrote: > >> > >> While in some cases deriving an AT&T-style suffix from an Intel syntax > >> memory operand size specifier is necessary, in many cases this is not > >> only pointless, but has led to the introduction of various workarounds: > >> Excessive use of IgnoreSize and NoRex64 as well as the ToDword and > >> ToQword attributes. Suppress suffix derivation when we can clearly tell > >> that the memory operand's size isn't going to be needed to infer the > >> possible need for the low byte/word opcode bit or an operand size prefix > >> (0x66 or REX.W). > >> > >> As a result ToDword and ToQword can be dropped entirely, plus a fair > >> number of IgnoreSize and NoRex64 can also be got rid of. Note that > >> IgnoreSize needs to remain on legacy encoded SIMD insns with GPR > >> operand, to avoid emitting an operand size prefix in 16-bit mode. (Since > >> 16-bit code using SIMD insns isn't well tested, clone an existing > >> testcase just enough to cover a few insns which are potentially > >> problematic but are being touched here.) > >> > >> As a side effect of folding the VCVT{,T}S{S,D,H}2SI templates, > >> VCVT{,T}SH2SI will now allow L and Q suffixes, consistent with > >> VCVT{,T}S{S,D}2SI. All of these remain inconsistent with their 2USI > >> counterparts (which I think should also be corrected, but perhaps better > >> in a separate change). > > > > I don't think allowing more unnecessary L and Q suffixes for AVX > > instructions is desirable. I prefer not to allow unnecessary L and > > Q suffixes in folded entries. We can add special entries to allow > > the existing instructions with suffixes. > > I think we've been there before, and I continue to think that we should > be consistent throughout the entire ISA in allowing suffixes when GPRs > or their equivalent memory operands are involved. That's in the spirit > of the original AT&T syntax intentions, after all. I have to admit that > I find it particularly worrying that you suggest to introduce new > templates, when the overall / long term goal is to reduce the set, to > keep it manageable in spite of all the new additions that yer yet to > come. > > As pointed out elsewhere, any inconsistencies here make it harder for > people to write e.g. heavily macro-ized code. Similarly it can result > in surprises when cloning existing code to deal with new extensions. > Will it work without unnecessary suffixes? -- H.J.