From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x35.google.com (mail-oa1-x35.google.com [IPv6:2001:4860:4864:20::35]) by sourceware.org (Postfix) with ESMTPS id 6142238AA265 for ; Thu, 17 Nov 2022 01:55:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6142238AA265 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oa1-x35.google.com with SMTP id 586e51a60fabf-13bef14ea06so624379fac.3 for ; Wed, 16 Nov 2022 17:55:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=bdneKzAJJJUZfQsnPS5GQ7s7aBLTaXKu+vQS6heu7+0=; b=VVQc4NR03y1qnEUTD1iIq6UqCuLcLNB49eE+FQjR5XRTEhNfTXMaoadaNg4HIJS1DH U2JNAqLsdm7lZLcZJa4pTvTdiCnFW0KHECZk0gyaisiNzQJm6cDXMGsNIyvG2sD+IGvE N12budcKOOZaxqlFZD0+cS4sQbF0w4OHUwihrUq+xSC8Tu07B9KQJO1aCys9mTwLGf95 1ud9zQUm2TE7AIHd95O7zjutHtiTv6cHeav8yA0mVGnQ1svtp0p7R5gY/woA9WJS8cQH iWfBeI5qLpRP/+BYWTk6S6ACD1xYD4gM6qKbalov72HGFPcusfh1kdzHA4bpvCsOA99y Zfjg== 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:subject:date:message-id :reply-to; bh=bdneKzAJJJUZfQsnPS5GQ7s7aBLTaXKu+vQS6heu7+0=; b=L2B3cqpnjzHJz4eGeiRAC8jjuQTuzb3pxpnoKNV9n6n+DCguU6tHaHMxuNbhT5MBAA 3pTRpqwKsWU/esfzJ5N2kwvm+gtrDkQLyGkhljR/kcd/V61tgRbh9XyYo85GBnG4wyiH jAtMQFHbC3lrngiE5zJ/oBVpOvr/okUaxOIybGOcQ+w2l/DvfK2kDXKO12/UGVAXex1I p+TSZ5jlo77XVK2+pnO+7/0/kMQbooLdYRnliWC8DKhE5cogyJN74IZ4Jem9GWjwbSIZ ooo6KMZourqSyVKhCGNfc7EnwpIWNI9UgL3C+HcrtU8wugRokz3Bu8qCUwe4AYxwjPTG N78Q== X-Gm-Message-State: ANoB5pnAaUiS8PSIYUPtcmzR9mRdtIYK06bbbjnEovHdgAsnbI/KyxH/ 5bpmfQKT/7Pe+C6vDuNZ/pFw+34wdO7B+6v/q3Y= X-Google-Smtp-Source: AA0mqf46LKsGOzfkSWYVbrV5Pxc6VaTrbVPJBah5iUxBe79bMQz51zKk5i7Pgw6cvVMatuzG3ErFqaj/8nQvaKMPZus= X-Received: by 2002:a05:6871:4501:b0:13c:5da4:7229 with SMTP id nj1-20020a056871450100b0013c5da47229mr204243oab.266.1668650108723; Wed, 16 Nov 2022 17:55:08 -0800 (PST) MIME-Version: 1.0 References: <3dd1c6f9-a773-c05f-44d7-12b7947072d2@suse.com> In-Reply-To: From: "H.J. Lu" Date: Wed, 16 Nov 2022 17:54:32 -0800 Message-ID: Subject: Re: [PATCH] x86: infer No_*Suf from other insn attributes To: Jan Beulich Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3016.6 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 autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, Nov 14, 2022 at 11:27 PM Jan Beulich wrote: > > On 15.11.2022 00:33, H.J. Lu wrote: > > On Mon, Nov 14, 2022 at 8:12 AM Jan Beulich wrote: > >> --- a/opcodes/i386-opc.tbl > >> +++ b/opcodes/i386-opc.tbl > >> @@ -75,12 +75,17 @@ > >> #define Size32 Size=SIZE32 > >> #define Size64 Size=SIZE64 > >> > >> +#define IsPrefix IsPrefix|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf > >> + > > > > I prefer to add > > > > #define No_Suf No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf > > > > to cover more templates. > > Iirc you said so two years ago already in the context of "x86: imply > all No_*Suf when none is set in a template". Yet as before I don't > like going that route, as that still leaves clutter on the respective > lines (even if it's less clutter then). Plus the ultimate goal, as > also said back then, ought to be to move from negative to positive > forms. Doing things the way done here will avoid touching all those > lines again which are being touched here. > > As a compromise I'd accept introducing NoSuf (or No_Suf) in addition > to the changes done here, for use on applicable lines not touched > here already, and for use in the #define-s I'm adding. I'd prefer > this to be a separate, subsequent patch though (to limit patch size, > focusing on one transformation at a time. (I could introduce the new > macro in a prereq patch, using it for only AddrPrefixOpReg right away, > then have the patch here use it in the new macros, and finally add one > to use the new macro on the remaining applicable templates.) An explicit NoSuf (or No_Suf) is better. > >> @@ -125,6 +130,11 @@ > >> #define VecSIB512 SIB=VECSIB512 > >> #define Sibmem SIB=SIBMEM|Modrm > >> > >> +#define SIB No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|SIB > > > > Where is this used? > > Half of the uses are even visible in patch context of this very hunk. > The other two are immediately ahead, just outside of patch context. > > One more general request, which is particularly relevant on a large > patch like this one: Can you please trim reply context? Below here > you did leave over a thousand lines of patch content, leaving me and > any potential other reader to scroll through to see whether there's > any further comment. > Sure. -- H.J.