From: "H.J. Lu" <hjl.tools@gmail.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Binutils <binutils@sourceware.org>
Subject: Re: [PATCH] x86: infer No_*Suf from other insn attributes
Date: Wed, 16 Nov 2022 17:54:32 -0800 [thread overview]
Message-ID: <CAMe9rOruh52qWi94zxWZyWxtVyn-zOMZQmmFVjCRXSiQ4wbKiQ@mail.gmail.com> (raw)
In-Reply-To: <a2cc13a3-8e3c-f6fc-0594-0ea34bc4e801@suse.com>
On Mon, Nov 14, 2022 at 11:27 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 15.11.2022 00:33, H.J. Lu wrote:
> > On Mon, Nov 14, 2022 at 8:12 AM Jan Beulich <jbeulich@suse.com> 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.
next prev parent reply other threads:[~2022-11-17 1:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-14 16:12 Jan Beulich
2022-11-14 23:33 ` H.J. Lu
2022-11-15 7:27 ` Jan Beulich
2022-11-17 1:54 ` H.J. Lu [this message]
2022-11-17 8:50 ` Jan Beulich
2022-11-17 17:21 ` H.J. Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMe9rOruh52qWi94zxWZyWxtVyn-zOMZQmmFVjCRXSiQ4wbKiQ@mail.gmail.com \
--to=hjl.tools@gmail.com \
--cc=binutils@sourceware.org \
--cc=jbeulich@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).