[PATCH] x86: Properly encode vmovd with 64-bit memeory

H.J. Lu hjl.tools@gmail.com
Mon Jan 8 11:52:00 GMT 2018


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
vmovd %rax, %xmm19
vmovd %xmm19, 128(%rax)
vmovd %xmm19, %rax
.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.

-- 
H.J.



More information about the Binutils mailing list