[PATCH v2] Support Intel AVX10.1

[Jan Beulich]

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

Jan