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

[Jan Beulich <jbeulich at suse dot com>]

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
alternative mnemonics: MOVSLL and (AMD64 only) MOVSLW (no
matter how odd they may look).

Jan