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