[PATCH v2] Support Intel AVX10.1

[Jan Beulich]

On 17.08.2023 11:08, Jan Beulich via Binutils wrote:
> On 16.08.2023 10:59, Jan Beulich via Binutils wrote:
>> On 16.08.2023 10:21, Jiang, Haochen wrote:
>>>>> After I think twice on that, I suppose maybe it is not that appropriate to put it
>>>>> into i386_opcode_modifier since in AVX10, the vector width is depends on CPU.
>>>>> I suppose i386_opcode_modifier is a feature for instructions but not CPU.
>>>>
>>>> I disagree. See the uses of EVex, for example. As said above, I think
>>>> maximum vector width and ISA extensions want dealing with separately,
>>>> and only the latter would generally qualify for Cpu* flags. Furthermore
>>>> recall that the attribute wants widening sooner or later, and Cpu*
>>>> flags are uniformly boolean. Only attributes may have numeric values.
>>>
>>> After I checked code, I still miss the point here.
>>>
>>> My concern is how to actually disable the zmm registers for AVX10/256
>>> and ymm registers for theoretical AVX10/128.
>>
>> That's the easy part: That'll want doing in check_register(). The issue
>> is with insns which do 512-bit operation despite not using zmm registers
>> (think of vfpclassp* with memory operand).
>>
>>> I suppose i386_opcode_modifier
>>> is more related to building up the whole encoding. But each AVX10.X/256 is an
>>> actual arch.
>>
>> I wouldn't agree with the last sentence, but ...
>>
>>> Adding a feature in i386_opcode_modifier can indicate what is the maximum
>>> vector length the instruction is allowed on all archs but has nothing to do with
>>> disabling zmm registers on an 256-bit only arch.
>>
>> ... you still have a point here. Maybe it only wants to be a boolean,
>> indicating that an insn is vector-length sensitive. Yet re-using the
>> EVex attribute continues to be an option: With vector length
>> constrained to 256 (or 128) bits, EVEX512 (or EVEX256) simply become
>> unavailable for encoding, and EVEXDYN would be equally constrained.
>> And if re-using that attribute continues to be an option, adding a
>> new non-boolean attribute clearly is also possible.
>>
>> So I guess there may have been a slight misunderstanding: I was
>> suggesting an attribute expressing permissible vector lengths (hence
>> the consideration of re-using EVex), which would then be checked
>> against the established (through whatever directive / command line
>> option) maximum vector length. I did not suggest a new "max vector
>> length" attribute.
> 
> Just to mention it: I've meanwhile realized that re-using EVex here will
> collide with APX introducing EVEX-encoded KMOV*. So it'll need to be a
> very similar but distinct attribute. And if it turned out that the
> attribute then is really only needed on the mask insns (using EVex
> elsewhere), it could equally well be a "permitted vector lengths" or a
> "maximum vector length" one, as both are then equal. Question is what
> AVX10/128 would mean for VEX-encoded insns. It seems likely that 256-bit
> forms wouldn't be permitted there either then, in which case applicable
> VEX-encoded insns would then need to gain such attributes as well. In
> that case it would of course be more logical to stick to "permitted
> vector lengths".

Sorry, yet another update. For one it can't be "maximum", but only
"minimum". And I meanwhile think "permitted" along the lines of EVex
won't catch it either. I guess I will want to take a stab myself ...

Jan