x86: Support Intel AVX VNNI

[H.J. Lu]

On Fri, Oct 23, 2020 at 12:04 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> 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.

{vex} and {vex3} aren't new.   The new behavior of AVX VNNI is that
{vex} or {vex3} is now mandatory for AVX VNNI.  Since {vex} or {vex3}
is mandatory for AVX VNNI, it shouldn't be dropped in disassembler
output.

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

We can change disassembler output from {vex3} to {vex} and
put back the {vex3| tests in AVX VNNI.

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

BTW, there are limitation in Intel syntax when used with GCC:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929

I don't know if it can be fixed.

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

x86 is still evolving.  We are trying to do things reasonably.

-- 
H.J.