This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

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.

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.

Jan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]