x86: Support Intel AVX VNNI

[Jan Beulich]

On 23.10.2020 03:57, Cui, Lili wrote:
>>> output helping in any way, when comparing to all other AVX+ insns
>>> which have AVX512VL counterparts? (Apart from that I'd further
>>> question why it needs to be {vex3} when {vex} would suffice, but I'd
>>> like to see this dropped altogether anyway, except perhaps in some
>>> non-default mode, where it then should be output consistently.)
>>
>> Yes, {vex3} can be dropped from AVX VNNI tests.

Okay, so we must have been talking past one another. I don't
see any good in dropping the tests, and this isn't what I did
suggest or talk about. {vex3} should be tested to be
properly accepted by the assembler, just like {vex}. What I
was saying is that _objdump output_ should have {vex} dropped,
and that it should have been {vex} instead of {vex3} there in
the first place.

Hence faod: I think the change here is wrong and should either
not be committed or reverted. (Oddly enough there have been no
Intel syntax checks of any prefix uses at all - I would
otherwise have outright nak-ed the change.)

And just to repeat - there might then want to be a non-default
disassembly mode which allows printing {vex} and alike. There
(and only there) it should then be the shortest unambiguous
form of prefix which gets output (in particular meaning no
prefix at all if an insn is unambiguous without; just like for
insn suffixes in AT&T mode there may then be a yet more verbose
mode where {vex} and alike get output unconditionally).

I can only re-iterate that this feature addition points out a
fundamental shortcoming: What would have needed to be
established first (and in public!) is an underlying abstract
model individually for both assembler and disassembler, that
we want each one to honor respectively. Once such a model is
agreed upon, verifying whether a particular change meets the
specification would be much easier. The primary goal of such
an abstract model would be consistency. As said in many other
contexts, being consistent is the only way to avoid surprises
to the user. I've been eliminating quite a few inconsistencies
over the last couple of years; some further attempts of doing
so were refused (or reverted) for reasons I didn't buy.

Jan