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