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