From: Jan Beulich <jbeulich@suse.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Binutils <binutils@sourceware.org>
Subject: Re: [PATCH v5 8/8] x86: further re-work insn/suffix recognition to also cover MOVSX
Date: Wed, 26 Oct 2022 11:07:06 +0200 [thread overview]
Message-ID: <3ed9f6ae-ab9f-efc3-8b11-b3fd0a4dcfaa@suse.com> (raw)
In-Reply-To: <CAMe9rOrMU2oUk9uBhfzOX6ADYJEvn+mhuHwgFN3-h41ouu81PQ@mail.gmail.com>
On 25.10.2022 19:10, H.J. Lu wrote:
> On Tue, Oct 25, 2022 at 12:29 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> PR gas/29524
>>
>> Having templates with a suffix explicitly present has always been
>> quirky. After prior adjustment all that's left to also eliminate the
>
> I prefer keeping the current MOVS behavior. Please submit a new patch
> set without MOVS changes.
You're kidding? If you _still_ think this patch isn't worth it despite
its merits, and despite it now only reducing the set of templates and
adjusting/extending the testsuite, without any changes to tc-i386.c you
can simply give your okay to the first 7 patches. Why would I spam the
list with an identical re-submission of those first 7 patches?
Independent of that I'd like to understand the reasons for your
preference, in particular when considering the benefits as well as the
reported bug which is being fixed (and which you marked as WONTFIX for
a subjective reason). So far your objection was that the change
complicates the code. Now it actually simplifies it slightly by
halving the number of involved templates.
Jan
next prev parent reply other threads:[~2022-10-26 9:07 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-25 7:23 [PATCH v5 0/8] x86: suffix handling changes Jan Beulich
2022-10-25 7:24 ` [PATCH v5 1/8] x86: constify parse_insn()'s input Jan Beulich
2022-10-25 7:25 ` [PATCH v5 1/8] x86: introduce Pass2 insn attribute Jan Beulich
2022-10-25 7:30 ` [PATCH v5 2/8] " Jan Beulich
2022-10-25 7:26 ` [PATCH v5 3/8] x86: re-work insn/suffix recognition Jan Beulich
2022-10-27 17:21 ` H.J. Lu
2022-10-28 9:00 ` Jan Beulich
2022-10-28 16:12 ` H.J. Lu
2022-10-31 11:40 ` Jan Beulich
2022-10-31 16:59 ` H.J. Lu
2022-10-25 7:26 ` [PATCH v5 4/8] ix86: don't recognize/derive Q suffix in the common case Jan Beulich
2022-10-25 7:27 ` [PATCH v5 5/8] x86-64: allow HLE store of accumulator to absolute 32-bit address Jan Beulich
2022-10-25 7:27 ` [PATCH v5 6/8] x86: move bad-use-of-TLS-reloc check Jan Beulich
2022-10-25 7:28 ` [PATCH v5 7/8] x86: drop (now) stray IsString Jan Beulich
2022-10-25 7:29 ` [PATCH v5 8/8] x86: further re-work insn/suffix recognition to also cover MOVSX Jan Beulich
2022-10-25 17:10 ` H.J. Lu
2022-10-26 9:07 ` Jan Beulich [this message]
2022-10-27 0:11 ` H.J. Lu
2022-10-27 6:31 ` 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=3ed9f6ae-ab9f-efc3-8b11-b3fd0a4dcfaa@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).