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

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Mon, Jan 8, 2018 at 12:48 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 08.01.18 at 02:18, <hongjiu.lu@intel.com> wrote:
>> For historical reason, we allow movd/vmovd with 64-bit register and
>> memeory operands.  But for vmovd, we failed to handle 64-bit memeory
>> operand.  This has been gone unnoticed since AT&T syntax always treats
>> memory operand as 32-bit memory.  This patch properly encodes vmovd
>> with 64-bit memeory operands.
>
> Interesting coincidence - just over the weekend I've run into this
> issue too. My intended solution is quite different, though: Since
> VMOVD (other than MOVD) doesn't have a 64-bit operand variant
> in either Intel's SDM nor AMD's PM, I'd rather remove memory
> operand support from it:
> - generate code was wrong so far, so anyone having used it would
>   have run buggy code anyway,
> - old gcc only ever uses the 64-bit variants with register operands.

Works for me.  Can you submit a patch?

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

> One other oddity I've noticed in this context is the difference in
> encoding choice between AVX and AVX512 VMOVQ with memory
> operand: While the former uses the forms allowing for an XMM
> register as alternative to the memory operand, the latter uses
> the forms alternatively allowing for a GPR in 64-bit mode, and
> the other one only in 32-bit mode. There's no comment there, so
> I wonder whether this is intentional or an unnecessary
> divergence.

I prefer to leave it alone.

Thanks.

-- 
H.J.