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 3:14 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> 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?

If we do that, should we also remove MOVD with 64-bit memory?
Otherwise, -msse2avx won't work on MOVD with 64-bit memory.

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



-- 
H.J.