On Wed, Feb 5, 2020 at 4:48 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 05.02.2020 13:44, H.J. Lu wrote:
> > 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]$
>
> I'm sorry, but I have no idea what you're trying to tell or
> demonstrate me with this. Things being the way you show them
> right now does in no way mean this is how they should be.
* 'movslq' with AT&T mnemonic only accepts 64-bit destination
register. 'movsxd' should be used to encode 16-bit or 32-bit
destination register with both AT&T and Intel mnemonics.
> Jan
>
> >> alternative mnemonics: MOVSLL and (AMD64 only) MOVSLW (no
> >> matter how odd they may look).
> >>
> >> Jan
> >
> >
> >
>
--
H.J.