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 1/7] x86/Intel: restrict suffix derivation
Date: Fri, 19 Aug 2022 10:19:56 +0200	[thread overview]
Message-ID: <ee7070db-78ac-a478-9aca-96daf266d954@suse.com> (raw)
In-Reply-To: <CAMe9rOpbh45iHmwpVQ_g6YpFFMxJLnhaCroAi0pja7AOa_BM7A@mail.gmail.com>

On 18.08.2022 16:46, H.J. Lu wrote:
> On Wed, Aug 17, 2022 at 11:08 PM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 17.08.2022 21:19, H.J. Lu wrote:
>>> On Tue, Aug 16, 2022 at 12:30 AM Jan Beulich <jbeulich@suse.com> 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
them. One possible reason for that could be to have the re-assurance of
the assembler pointing out mismatches between suffix and operand(s).

Jan

  reply	other threads:[~2022-08-19  8:20 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-16  7:27 [PATCH 0/7] x86: suffix handling changes Jan Beulich
2022-08-16  7:30 ` [PATCH 1/7] x86/Intel: restrict suffix derivation Jan Beulich
2022-08-17 19:19   ` H.J. Lu
2022-08-18  6:07     ` Jan Beulich
2022-08-18 14:46       ` H.J. Lu
2022-08-19  8:19         ` Jan Beulich [this message]
2022-08-19 14:23           ` H.J. Lu
2022-08-19 14:49             ` Jan Beulich
2022-08-19 17:00               ` H.J. Lu
2022-08-22  9:34                 ` Jan Beulich
2022-08-22 14:38                   ` H.J. Lu
2022-08-16  7:30 ` [PATCH 2/7] x86: insert "no error" enumerator in i386_error enumeration Jan Beulich
2022-08-17 19:19   ` H.J. Lu
2022-08-16  7:31 ` [PATCH 3/7] x86: move / quiesce pre-386 non-16-bit warning Jan Beulich
2022-08-17 19:21   ` H.J. Lu
2022-08-18  7:21     ` Jan Beulich
2022-08-18 15:30       ` H.J. Lu
2022-08-19  6:13         ` Jan Beulich
2022-08-19 14:18           ` H.J. Lu
2022-08-16  7:32 ` [PATCH 4/7] x86: improve match_template()'s diagnostics Jan Beulich
2022-08-17 20:24   ` H.J. Lu
2022-08-18  6:14     ` Jan Beulich
2022-08-18 14:51       ` H.J. Lu
2022-08-16  7:32 ` [PATCH 5/7] x86: re-work insn/suffix recognition Jan Beulich
2022-08-17 20:29   ` H.J. Lu
2022-08-18  6:24     ` Jan Beulich
2022-08-18 15:14       ` H.J. Lu
2022-08-19  8:28         ` Jan Beulich
2022-08-23  2:00           ` H.J. Lu
2022-08-26  9:26             ` Jan Beulich
2022-08-26 18:46               ` H.J. Lu
2022-09-06  6:40                 ` Jan Beulich
2022-09-06 21:53                   ` H.J. Lu
2022-09-07  7:17                     ` Jan Beulich
2022-09-26 23:52                       ` H.J. Lu
2022-09-28 12:49                         ` Jan Beulich
2022-09-28 19:33                           ` H.J. Lu
2022-09-29  8:08                             ` Jan Beulich
2022-09-29 16:00                               ` H.J. Lu
2022-09-29 16:06                                 ` Jan Beulich
2022-09-29 16:20                                   ` H.J. Lu
2022-08-16  7:33 ` [PATCH 6/7] x86-64: further re-work insn/suffix recognition to also cover MOVSL Jan Beulich
2022-08-16  7:34 ` [PATCH 7/7] ix86: don't recognize/derive Q suffix in the common case Jan Beulich
2022-08-17 20:36   ` H.J. Lu
2022-08-18  6:29     ` Jan Beulich

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=ee7070db-78ac-a478-9aca-96daf266d954@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).