From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) by sourceware.org (Postfix) with ESMTPS id 184853858C55 for ; Fri, 19 Aug 2022 14:24:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 184853858C55 Received: by mail-qk1-x735.google.com with SMTP id g16so3327809qkl.11 for ; Fri, 19 Aug 2022 07:24:32 -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=xCkwP07rcWmVq4l4ukjnr5ieQuASJMLNO2AteYj4BI8=; b=k3rnHGmwOptVe7UXUZWYYTCW3I5HElIe17b38ViPfmJZVxq7NHOk1VM2N9PXFyKrGe t7C/0oTJ3oHJgG/5WUdVqBhH8+OOzjUlaDiD0KCfUDtLDqSONh82IMsw2A2JXpf+W+3F NnVV1wj94sxA9SwJcJzuIuyvhNxwI5m99/8TUEh15GNyYA369CpNs32g+kp5KIGeqTRr OJJoPwlPyNuUnfTN0iv8nEDiZdhLcJ97bcUxSsEv1MKopl6YufpdK4hpXJCuIXj6uaTz bnrKl//k7DRxSs1tzrOW808NHuvUnCQ3YVbHArVC1cbu4EL8w5It9LN6H44JZ575KfJA CfVg== X-Gm-Message-State: ACgBeo1qi8TNl3nEGNK+bFWqcAHDj721q/ihZT8jwGHgD3ViZCB2YT6L 2CYcqu/ab3gv2ILFbFsHfR537JhnXO5PC5dRGvgXINKx X-Google-Smtp-Source: AA6agR4GwexFPT1XRQQwG2pbjOU7wVczwMmB5gzHxzVOW5OBqVFxZX9Yzwe0EkAX96Hj4aDcW4RXlNzzdtSn192xrVk= X-Received: by 2002:a05:620a:25d4:b0:6a8:d56c:5c75 with SMTP id y20-20020a05620a25d400b006a8d56c5c75mr5308853qko.81.1660919071363; Fri, 19 Aug 2022 07:24:31 -0700 (PDT) MIME-Version: 1.0 References: <32216291-fd1f-4579-87de-d24cb7190894@suse.com> In-Reply-To: From: "H.J. Lu" Date: Fri, 19 Aug 2022 07:23:55 -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.3 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: Fri, 19 Aug 2022 14:24:33 -0000 On Fri, Aug 19, 2022 at 1:20 AM Jan Beulich wrote: > > On 18.08.2022 16:46, H.J. Lu wrote: > > 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? > > I'm afraid I can only guess at what "it" means in your reply. Of course > things will work for people who have never used what you call > "unnecessary" prefixes. But there are other people who believe that the > spirit of AT&T syntax is to put suffixes everywhere where multiple > operand sizes are possible, and where the suffix allows to distinguish In glibc, integer instructions without suffixes are used to support different vector sizes. > them. One possible reason for that could be to have the re-assurance of > the assembler pointing out mismatches between suffix and operand(s). -- H.J.