[PATCH] Support Intel AVX10.1

[Jan Beulich]

On 01.08.2023 04:18, Jiang, Haochen wrote:
>> Alternative proposal: No addition to i386-opc.h at all, and here
>> simply set/clear the combination of all covered AVX512 (sub)features
>> (for clearing that'll imply clearing all others as well, obviously).
>> From my earlier comments I think that'll leave only the /256 (and
>> the perhaps theoretical only /128) AVX10.x sub-feature handling.
>> That, I think, wants dealing with by merely disallowing use of the
>> ZMM registers (when disabling /512) and the high YMM ones (when
>> disabling /256, assuming we want to allow for the AVX10.1/128
>> feature, which I think we should even if the doc says nothing like
>> that is planned right now for hardware). How to neatly express that
>> is an open question, because we may want this to remain orthogonal
>> to the actual AVX10.x features. Maybe something like .noavx10.x/512
>> (with 'x' meaning literal 'x', i.e. not as kind of a "wildcard"
>> covering multiple such directives), except I think the slash is
>> going to be a problem (yet it would be nice to stick to doc naming).
>> In any event this wouldn't be possible to express by another table
>> entry, but would require handling "manually".
> 
> I will give a try on that, should not be too complex.
> 
> The biggest "manual" part might be mask instructions (e.g. kaddq)
> since w/o vector registers, we do not know the size of the mask
> registers from operand property. The only way to know them is
> from the instruction name.

Most k...q insns are VEX.W1 NP ones, aren't they? That should limit
the amount of special casing based on mnemonic.

Jan