[PATCH 1/2] [PATCH 1/2] Enable Intel AVX512_FP16 instructions

[Jan Beulich]

On 01.07.2021 09:47, Cui,Lili wrote:
>  opcodes/i386-opc.tbl           | 376 +++++++++++++++++++++

A few more observations:

While personally I think what you have is the best way of encoding
it (allowing 64-bit register use to control EVEX.W in 64-bit bit
mode), VMOVW is neither consistent with VPEXTRW (using EvexWIG) nor
with VMOVD (only permitting Reg32). H.J., what are your thoughts
here?

The VMOVW template needs splitting afaict: By OR-ing Word with
Reg32 and/or Reg64, you effectively also permit Reg16, and I guess
in Intel syntax VMOVW memory operands using "dword ptr" or
"qword ptr". You'll notice that e.g. {,V}PEXTRW and {,V}PINSRW
have separate register and memory operand templates, which is for
this reason, iirc. (You may recall my other remark regarding
combining e.g. Reg32 and Dword - there it is merely redundant, but
having such is liable to suggest to people that combinations like
Reg32 and Word are also okay. I intend to have i386-gen warn about
such down the road, but obviously only once all present redundancies
have been eliminated.)

VCVT{,T}SH2{,U}SI should have EvexWIG for their non-64bit encodings.
But really it's unclear why each of them has three templates when
the corresponding pre-existing SD and SS insns get away with two. I
would have expected new templates to have been cloned from similar
existing ones, rather than introducing new ones (with new
inconsistencies). Of course there's (again) the possibility that
you've spotted a bug with pre-existing templates, but then - if you
don't want to fix those right away - I'd expect you to at least
point out why you deviate from what we've got.

I suppose VCMP{P,S}H should have a large set of pseudos just like
VCMP{P,S}{S,D} do, even if (for now) the spec doesn't spell those
out.

Jan