This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] x86: Properly encode vmovd with 64-bit memeory
>>> On 08.01.18 at 12:52, <hjl.tools@gmail.com> wrote:
> On Mon, Jan 8, 2018 at 3:39 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 08.01.18 at 12:14, <hjl.tools@gmail.com> wrote:
>>> On Mon, Jan 8, 2018 at 12:48 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> Furthermore I think that the AVX512 64-bit variant should go away
>>>> altogether - it's register form is just a longer re-encoding of the
>>>> AVX form, and hence redundant, and gcc (afaics) doesn't use it.
>>>
>>> Shouln't vmovd with upper 32 xmm registers be encoded with AVX512?
>>
>> No, such an instruction simply doesn't exist (as per SDM). The
>
> What do you mean by that? These
>
> vmovd 128(%rax), %xmm19
As per the SDM this one is a 32-bit operation.
> vmovd %rax, %xmm19
As per the SDM this one doesn't exist.
> vmovd %xmm19, 128(%rax)
32-bit again.
> vmovd %xmm19, %rax
non-existing again.
> .intel_syntax noprefix
> vmovd xmm19, qword ptr [rax + 128]
> vmovd xmm19, rax
> vmovd qword ptr [rax + 128], xmm19
> vmovd rax, xmm19
>
> are encoded with AVX512.
>
>> difference to the AVX flavor is that gcc new enough to support
>> AVX512 is also new enough to check for the availability of the
>> well-formed VMOVQ, and there's also no mode equivalent to
>> SSE2AVX to take care of.
>
> GCC has
>
> case TYPE_SSEMOV:
> switch (get_attr_mode (insn))
> {
> case MODE_DI:
> /* Handle broken assemblers that require movd instead of movq. */
> if (!HAVE_AS_IX86_INTERUNIT_MOVQ
> && (GENERAL_REG_P (operands[0]) || GENERAL_REG_P (operands[1])))
> return "%vmovd\t{%1, %0|%0, %1}";
> return "%vmovq\t{%1, %0|%0, %1}";
>
> It doesn't check upper 32 xmm registers.
Ah, yes you're right. See also my other reply just sent.
Jan