I have constructed a fairly exhaustive test suite for the x86 assembler and identified some problems. The ones in this issue were added during the Go 1.6 cycle and should be corrected before the release. I intend to do this and also check in the tests.

Added in 9dd81d6, https://golang.org/cl/14127, Oct 5 2015:

MOVHDA X2, X11: have encoding "c57d6fda", want "c5796fda"
   0:   c5 7d 6f da             vmovdqa %ymm2,%ymm11
   0:   c5 79 6f da             vmovdqa %xmm2,%xmm11

MOVHDU X2, X11: have encoding "c57e6fda", want "c57a6fda"
   0:   c5 7e 6f da             vmovdqu %ymm2,%ymm11
   0:   c5 7a 6f da             vmovdqu %xmm2,%xmm11

It took me a while to figure out that VMOVDQU, VMOVDQA, and VMOVNTDQ have been renamed to MOVHDU, MOVHDA, and MOVNTHD. That's very strange. We don't use HD in place of DQ anywhere else, nor do we drop the leading V. We do use "O" in place of "DQ" in a number of places, and that would have been an OK convention to follow, but we also install aliases for the Intel names because this is all so confusing, and that wasn't done here, making the spellings chosen in this CL basically impossible to find. I only found them because I was looking for CLs related to the others below that caused test failures in instructions with more predictable names. These should be renamed, and I will do that.

Once renamed, there is still the issue, not mentioned anywhere in the CL description nor the code that the X registers (128-bit) are being reused here as identifiers for Y registers (256-bit that hold the 128-bit forms in their bottom halves). The motivation for changing VMOVDQ to MOVHD may have been to emphasize this fact, which I appreciate, but it would have been nice to discuss the overloading explicitly. I am not sure it's a great idea, since it leads to very confusing assembly. At the very least that fact needs clear documentation. It was just slipped in as far as I can tell.

The overloading of X and Y registers is handled here by changing the name but then all the followup instructions just silently used Y registers without name changes. In many cases it's hard to tell the difference, assuming you're okay with asking for an X instruction and getting one that does what you asked but also sets the high Y bits (the VEX instructions operating on X registers are documented to zero the high Y bits, not use them). But in at least one case it matters greatly: VPTEST on X registers is defined to only consider the low 128 bits in the comparison. If it silently compares the whole 256-bit Y register instead, that's sure to surprise someone (along with the fact that the top half has not been zeroed by all the earlier V instructions).

This is going to take a while to figure out, clean up, and document. Good thing there are a few days left before the release candidate.

Added in 0e23ca4, https://golang.org/cl/16434, Nov 2 2015:

VPCMPEQB X2, X9, X11: have encoding "c53574da", want "c4613174da"
   0:   c5 35 74 da             vpcmpeqb %ymm2,%ymm9,%ymm11
   0:   c4 61 31 74 da          vpcmpeqb %xmm2,%xmm9,%xmm11

VPMOVMSKB X2, R11: have encoding "c57dd7da", want "c46179d7da"
   0:   c5 7d d7 da             vpmovmskb %ymm2,%r11d
   0:   c4 61 79 d7 da          vpmovmskb %xmm2,%r11d

Added in 967564b, https://golang.org/cl/16481, Nov 5 2015:

VPAND X2, X9, X11: have encoding "c535dbda", want "c531dbda"
   0:   c5 35 db da             vpand  %ymm2,%ymm9,%ymm11
   0:   c5 31 db da             vpand  %xmm2,%xmm9,%xmm11

Added in 321a407, https://golang.org/cl/16484, Nov 6 2015:

VPBROADCASTB X2, X11: have encoding "c4627d78da", want "c4627978da"
   0:   c4 62 7d 78 da          vpbroadcastb %xmm2,%ymm11
   0:   c4 62 79 78 da          vpbroadcastb %xmm2,%xmm11

VPTEST X2, X11: have encoding "c4627d17da", want "c4627917da"
   0:   c4 62 7d 17 da          vptest %ymm2,%ymm11
   0:   c4 62 79 17 da          vptest %xmm2,%xmm11

Added in b597e1e, https://golang.org/cl/16773, Nov 24 2015:

VPXOR X2, X9, X11: have encoding "c535efda", want "c531efda"
   0:   c5 35 ef da             vpxor  %ymm2,%ymm9,%ymm11
   0:   c5 31 ef da             vpxor  %xmm2,%xmm9,%xmm11

Added in 1d1f2fb, https://golang.org/cl/18593, Jan 13 2016:

PEXTRQ  $7, X11, (BX): have encoding "6644480f3a161b07", want "664c0f3a161b07"
   0:   66 44                   data16 rex.R
   2:   48 0f 3a 16             rex.W (bad) 
   6:   1b 07                   sbb    (%rdi),%eax
   0:   66 4c 0f 3a 16 1b 07    pextrq $0x7,%xmm11,(%rbx)

   XDIS 0: SSE       SSE4       6644480F3A161B07         pextrq qword ptr [rbx], xmm3, 0x7
   XDIS 0: SSE       SSE4       664C0F3A161B07           pextrq qword ptr [rbx], xmm11, 0x7

The problem here, confusing both objdump and xed, is that there are two REX bytes! The 44 48 should be 4C. I'm amazed this executes. Maybe it doesn't.