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 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.
Jan