x86: Support Intel AVX VNNI

[Jan Beulich]

On 23.10.2020 15:17, H.J. Lu wrote:
> 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.

They're not helpful in the disassembler output, and their adding
is inconsistent with other cases where {vex} / {vex3} / {evex}
aren't being displayed despite being necessary in gas to achieve
the respective encoding.

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

Good, thanks.

>> 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've seen the notification, but didn't read the bug itself yet.
>From the title I'm inclined to say it can't be fixed in the
general case. Some common case may be possible to have a
workaround for.

Jan