[PATCH] x86-64: Properly encode and decode movsxd

[H.J. Lu]

On Wed, Feb 5, 2020 at 5:23 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 05.02.2020 14:17, H.J. Lu wrote:
> > On Wed, Feb 5, 2020 at 5:14 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 05.02.2020 14:03, H.J. Lu wrote:
> >>> 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.
> >>
> >> I think you've said exactly this before. I don't think, however,
> >> that this addresses in any way my most recent remark regarding
> >> the inconsistency of this.
> >>
> >
> > Some inconsistencies are unavoidable.  MOVSXD is one of them.
>
> Unavoidable? I've outlined how they could be avoided here. It's
> not like this can't be done properly. It's more like you don't
> want it to be so (sort of an excuse being that there's endless
> other inconsistencies, I guess, which I'm hoping to be able to
> slowly get rid of, but for some backwards compatibility
> considerations stand in the way).

We don't do at the expanse more complex suffix handling
and strange syntax like "movsxdl (%rax),%rcx".

-- 
H.J.