vcvtps2ph, vcvtpd2dq and other's register mnemonic doesn't match gas' and Intel's.

The AVX and AVX-512 form of vcvtps2ph that takes ymm and zmm sources is specified by Intel like this:

VEX.128.66.0F3A.W0 1D /r ib
VCVTPS2PH xmm1/m64, xmm2,
imm8

VEX.256.66.0F3A.W0 1D /r ib
VCVTPS2PH xmm1/m128, ymm2,
imm8

EVEX.128.66.0F3A.W0 1D /r ib
VCVTPS2PH xmm1/m64 {k1}{z},
xmm2, imm8

EVEX.256.66.0F3A.W0 1D /r ib
VCVTPS2PH xmm1/m128 {k1}{z},
ymm2, imm8

EVEX.512.66.0F3A.W0 1D /r ib
VCVTPS2PH ymm1/m256 {k1}{z},
zmm2{sae}, imm8

Note that the destination for ymm source is specified as xmm. However, the instruction does write zero [MAXVL-1:128]. There are plenty of examples in AVX and AVX-512 of instructions doing the same and their destination mnemonic always matches the source mnemonic. There doesn't seem to be anything special about vcvtps2ph in this regard.

DR does currently not make a special case for this instruction. It looks like that gas does.

  asm volatile("vcvtps2ph $1, %%xmm0, %%xmm1\n\t" : : :);
  /* Note that gas wants the destination's register mnemonic to be xmm */
  asm volatile("vcvtps2ph $1, %%ymm0, %%xmm1\n\t" : : :);                                                                                                                                                                                                                                
  /* Note that gas wants the destination's register mnemonic to be ymm */
  asm volatile("vcvtps2ph $1, %%zmm0, %%ymm1\n\t" : : :);

Unless it somehow becomes a problem, I would like it as-is, but I am filing this issue so this is known, in case this will come up again later.