This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] x86-64: Properly encode and decode movsxd
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Jan Beulich <jbeulich at suse dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Wed, 5 Feb 2020 04:44:11 -0800
- Subject: Re: [PATCH] x86-64: Properly encode and decode movsxd
- References: <20200123202450.12441-1-hjl.tools@gmail.com> <3a2bae0b-19b9-31f9-3665-841802bd0c84@suse.com> <CAMe9rOosYu++bdMhDv4NDOAW4Yi33nRu0TLYdVXxmAC6ObTLVQ@mail.gmail.com> <CAMe9rOr9j4hB1htCG9=PJNtHgPPigntaWNP_jQeFh3QzkcFG+Q@mail.gmail.com> <b6cb7678-9c77-7add-e68a-d0d2d08d4f3c@suse.com> <CAMe9rOqPynD6=MWGX3m+HMeLeM4+iCAAsTrzf=xgmQd5R8S7nQ@mail.gmail.com> <cf9e09f6-1824-c030-f10c-b26eeac77907@suse.com> <CAMe9rOpQMVGvsFpxBtPxpD7CE-oZukjjCPY0heQWFYk+=3WczA@mail.gmail.com> <dc8b261f-824c-b5a0-34ab-692edbcf59d4@suse.com>
On Wed, Feb 5, 2020 at 12:18 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 03.02.2020 18:19, H.J. Lu wrote:
> > On Mon, Feb 3, 2020 at 8:34 AM Jan Beulich <jbeulich@suse.com> wrote:
> >> On 03.02.2020 15:49, H.J. Lu wrote:
> >>> On Mon, Feb 3, 2020 at 12:38 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>> And you broke previously working code, which has no testcase so
> >>>> far, but which
> >>>> https://sourceware.org/ml/binutils/2019-12/msg00354.html
> >>>> adds a test for:
> >>>>
> >>>> movsxdl (%rax),%rcx
> >>>
> >>> This isn't valid AT&T mnemonic. No one should use it.
> >>
> >> Mind telling me what you derive this from? It is my understanding
> >> that the general rule of how to derive AT&T mnemonics is to take
> >> the Intel manual's mnemonic and add a set of suffixes if varying
> >
> > MOVSXD is a special case. The typical usages of AT&T syntax are
> >
> > movslq %eax, %rcx
> > movslq (%rax), %rcx
> >
> > Anything else should be MOVSXD without any suffixes. It is one
> > less mnemonic we need to apply complex suffix rules.
> >
> >> operand sizes are permitted. I can accept _new_ insns (in
> >> particular SIMD ones) to not get suffixes supported when they're
> >> not really needed. But this is an original x86-64 GPR insn. It
> >> should be consistent with other original x86-64 GPR insns.
> >>
> >> Furthermore, if it really was intentional for your commit to
> >
> > Yes, it was intentional.
>
> Well, okay then, I'll remove the addition from the patch. But
> I guess you realize that consistency here would mean to not
> allow MOVSXD at all in AT&T mode (or at least to not "prefer"
> it, just like for MOVSX), but instead have suitable
[hjl@gnu-cfl-2 tmp]$ cat x.s
movslq %eax, %rcx
movslq (%rax), %rcx
movsxd %eax, %rcx
movsxd (%rax), %rcx
movsxd %eax, %ecx
movsxd (%rax), %ecx
movsxd %eax, %cx
movsxd (%rax), %cx
[hjl@gnu-cfl-2 tmp]$ gcc -c x.s
[hjl@gnu-cfl-2 tmp]$ objdump -dw x.o
x.o: file format elf64-x86-64
Disassembly of section .text:
0000000000000000 <.text>:
0: 48 63 c8 movslq %eax,%rcx
3: 48 63 08 movslq (%rax),%rcx
6: 48 63 c8 movslq %eax,%rcx
9: 48 63 08 movslq (%rax),%rcx
c: 63 c8 movsxd %eax,%ecx
e: 63 08 movsxd (%rax),%ecx
10: 66 63 c8 movsxd %eax,%cx
13: 66 63 08 movsxd (%rax),%cx
[hjl@gnu-cfl-2 tmp]$
> alternative mnemonics: MOVSLL and (AMD64 only) MOVSLW (no
> matter how odd they may look).
>
> Jan
--
H.J.