public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Binutils <binutils@sourceware.org>
Subject: Re: [PATCH] x86: infer No_*Suf from other insn attributes
Date: Tue, 15 Nov 2022 08:27:42 +0100	[thread overview]
Message-ID: <a2cc13a3-8e3c-f6fc-0594-0ea34bc4e801@suse.com> (raw)
In-Reply-To: <CAMe9rOo6QSGOXqKhzxnyqfUDLY8b57GhEn2qb09zhkB5KYLh1Q@mail.gmail.com>

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.)

>> @@ -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.

Thanks, Jan

  reply	other threads:[~2022-11-15  7:27 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 [this message]
2022-11-17  1:54     ` H.J. Lu
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=a2cc13a3-8e3c-f6fc-0594-0ea34bc4e801@suse.com \
    --to=jbeulich@suse.com \
    --cc=binutils@sourceware.org \
    --cc=hjl.tools@gmail.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).