public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "binutils@sourceware.org" <binutils@sourceware.org>
Subject: [PATCH] x86: Remove movsx/movzx with memory operand from AT&T syntax
Date: Tue, 11 Feb 2020 20:12:00 -0000	[thread overview]
Message-ID: <CAMe9rOpVnsmzDe9n8KkkPS4qmhbLo5Uipa4T0NonVddaFv=WrQ@mail.gmail.com> (raw)
In-Reply-To: <CAMe9rOqEH9d=oUZc7bQ-WhQ26fKhD7P=zhLHyMGJGcwYqueaZA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5092 bytes --]

On Tue, Feb 11, 2020 at 9:04 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Tue, Feb 11, 2020 at 8:45 AM Jan Beulich <jbeulich@suse.com> wrote:
> >
> > On 11.02.2020 14:07, H.J. Lu wrote:
> > > On Tue, Feb 11, 2020 at 5:04 AM Jan Beulich <jbeulich@suse.com> wrote:
> > >>
> > >> On 11.02.2020 14:01, H.J. Lu wrote:
> > >>> On Tue, Feb 11, 2020 at 4:58 AM Jan Beulich <jbeulich@suse.com> wrote:
> > >>>>
> > >>>> On 11.02.2020 13:19, H.J. Lu wrote:
> > >>>>> On Tue, Feb 11, 2020 at 3:55 AM Jan Beulich <jbeulich@suse.com> wrote:
> > >>>>>>
> > >>>>>> On 11.02.2020 12:42, H.J. Lu wrote:
> > >>>>>>> On Tue, Feb 11, 2020 at 2:25 AM Jan Beulich <jbeulich@suse.com> wrote:
> > >>>>>>>>
> > >>>>>>>> Some encodings are about to gain a warning - move them from test cases
> > >>>>>>>> not expecting any diagnostics to the new, dedicated ones, to allow
> > >>>>>>>> better focus on the actual changes in the subsequent patch.
> > >>>>>>>>
> > >>>>>>>> The new tests added have some wrong expectations right now, which will
> > >>>>>>>> be corrected by the next patch. The test is being added here to make
> > >>>>>>>> more visible which cases actually were wrong (and hence get changed),
> > >>>>>>>> besides demonstrating that in the vast majority of cases the subsequent
> > >>>>>>>> change doesn't alter generated code.
> > >>>>>>>>
> > >>>>>>>> gas/
> > >>>>>>>> 2020-02-XX  Jan Beulich  <jbeulich@suse.com>
> > >>>>>>>>
> > >>>>>>>>         * testsuite/gas/i386/i386.s, testsuite/gas/i386/iamcu-1.s,
> > >>>>>>>>         testsuite/gas/i386/ilp32/x86-64.s: Move ambiguous operand size
> > >>>>>>>>         tests ...
> > >>>>>>>>         * testsuite/gas/i386/noreg16.s, testsuite/gas/i386/noreg32.s,
> > >>>>>>>>         testsuite/gas/i386/noreg64.s, testsuite/gas/i386/x86_64.s: ...
> > >>>>>>>>         here.
> > >>>>>>>>         * testsuite/gas/i386/i386.d, testsuite/gas/i386/i386-intel.d
> > >>>>>>>>         testsuite/gas/i386/iamcu-1.d, testsuite/gas/i386/ilp32/x86-64.d,
> > >>>>>>>>         testsuite/gas/i386/k1om.d, testsuite/gas/i386/l1om.d,
> > >>>>>>>>         testsuite/gas/i386/noreg16.d, testsuite/gas/i386/noreg32.d,
> > >>>>>>>>         testsuite/gas/i386/noreg64.d, testsuite/gas/i386/x86_64-intel.d,
> > >>>>>>>>         testsuite/gas/i386/x86_64.d: Adjust expectations.
> > >>>>>>>>         * testsuite/gas/i386/movx16.s, testsuite/gas/i386/movx16.l,
> > >>>>>>>>         testsuite/gas/i386/movx32.s, testsuite/gas/i386/movx32.l,
> > >>>>>>>>         testsuite/gas/i386/movx64.s, testsuite/gas/i386/movx64.l: New.
> > >>>>>>>>         * testsuite/gas/i386/i386.exp: Run new tests.
> > >>>>>>>
> > >>>>>>> Please make a separate patch to address MOVSX/MOVZX.
> > >>>>>>
> > >>>>>> I don't understand what you mean here. This patch simply documents the
> > >>>>>> status quo, to make it (much) easier to see what the next patch
> > >>>>>> actually adjusts. It doesn't "address" anything. If, for the purpose
> > >>>>>> of committing, you'd like to see both patches folded - fine by me. But
> > >>>>>> only then, not any earlier.
> > >>>>>>
> > >>>>>>>  MOVSX and MOVZX
> > >>>>>>> should take no suffixes.  AT&T syntax is supported if there is no
> > >>>>>>> ambiguity.  AT&T
> > >>>>>>> syntax also supports movsXY and movzXY.
> > >>>>>>
> > >>>>>> Please could you clarify what specifically you'd like to see changed,
> > >>>>>> at the very least by pointing out one case each where you think I'm
> > >>>>>> moving in the wrong direction (presumably in the next patch really)?
> > >>>>>> I'm afraid your response isn't such that I can derive from it what
> > >>>>>> exactly you want.
> > >>>>>
> > >>>>> We support
> > >>>>>
> > >>>>> movsx %ax, %ecx
> > >>>>> movzx %ax, %ecx
> > >>>>> movswl %ax, %ecx
> > >>>>> movzwl %ax, %ecx
> > >>>>>
> > >>>>> We disallow
> > >>>>>
> > >>>>> movsxw %ax, %ecx
> > >>>>> movzxw %ax, %ecx
> > >>>>
> > >>>> We don't (as this patch demonstrates, along with pre-existing tests,
> > >>>> unless you mean once again to have an inconsistency between insns
> > >>>> with all register operands and similar ones with e memory source),
> > >>>> and if you want it to be this way, then please do so yourself, but
> > >>>
> > >>> I will do it.
> > >>>
> > >>>> please also only on top of my changes, so I won't need to re-base
> > >>>
> > >>> Which changes of yours are you referring to?
> > >>
> > >> This patch and the subsequent one.
> > >>
> > >
> > > Both changes won't be necessary after my changes.
> >
> > I'm confused. What you want to deal with is - afaict - orthogonal to
> > what the next patch in the series here does.
> >
>
> You will see what I mean when I post my patch for review.
>

AT&T syntax requires suffix to specify memory operand size.  Since
movsx and movzx can have different memory operand sizes with the same
destination register, this patch removes movsx and movzx with memory
operand from AT&T syntax.  Since AT&T syntax uses different mnemonics
for movsx and movzx, this change should have little impact on assembly
sources.  Tested with Linux kernel 5.5.3 for x86-64 and glibc 2.31 for
i686 and x86-64.

-- 
H.J.

[-- Attachment #2: 0001-x86-Remove-movsx-movzx-with-memory-operand-from-AT-T.patch --]
[-- Type: application/x-patch, Size: 42162 bytes --]

  reply	other threads:[~2020-02-11 20:12 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-11 10:23 [PATCH v5 0/5] x86: operand size handling improvements Jan Beulich
2020-02-11 10:25 ` [PATCH v5 2/5] x86: move certain MOVSX/MOVZX tests Jan Beulich
2020-02-11 11:43   ` H.J. Lu
2020-02-11 11:55     ` Jan Beulich
2020-02-11 12:20       ` H.J. Lu
2020-02-11 12:58         ` Jan Beulich
2020-02-11 13:02           ` H.J. Lu
2020-02-11 13:04             ` Jan Beulich
2020-02-11 13:07               ` H.J. Lu
2020-02-11 16:45                 ` Jan Beulich
2020-02-11 17:04                   ` H.J. Lu
2020-02-11 20:12                     ` H.J. Lu [this message]
2020-02-11 23:34                       ` [PATCH] x86: Remove movsx/movzx with memory operand from AT&T syntax H.J. Lu
2020-02-11 23:52                         ` H.J. Lu
2020-02-12  3:19                           ` [PATCH] x86: Remove movsx/movzx with 16/32-bit " H.J. Lu
2020-02-12  9:19                             ` Jan Beulich
2020-02-11 10:25 ` [PATCH v5 1/5] x86: also disallow non-byte/-word registers with byte/word suffix Jan Beulich
2020-02-11 11:27   ` H.J. Lu
2020-02-11 10:25 ` [PATCH v5 3/5] x86: replace adhoc (partly wrong) ambiguous operand checking for MOVSX/MOVZX Jan Beulich
2020-02-11 10:26 ` [PATCH v5 4/5] x86: correct VFPCLASSP{S,D} operand size handling Jan Beulich
2020-02-11 11:50   ` H.J. Lu
2020-02-11 12:49     ` Jan Beulich
2020-02-11 12:56       ` H.J. Lu
2020-02-11 10:27 ` [PATCH v5 5/5] x86-64: Intel64 adjustments for insns dealing with far pointers Jan Beulich
2020-02-11 11:53   ` H.J. Lu
2020-02-12  8:11     ` 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='CAMe9rOpVnsmzDe9n8KkkPS4qmhbLo5Uipa4T0NonVddaFv=WrQ@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).