Re: [PATCH v2] Support Intel AVX10.1

[Jan Beulich <jbeulich@suse.com>]

On 15.08.2023 10:32, Jiang, Haochen wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Monday, August 14, 2023 6:34 PM
>> To: Jiang, Haochen <haochen.jiang@intel.com>
>> Cc: binutils@sourceware.org; hjl.tools@gmail.com
>> Subject: Re: [PATCH v2] Support Intel AVX10.1
>>
>> On 14.08.2023 10:46, Jiang, Haochen wrote:
>>>> Before I get into any details here, I'd like to understand why there
>>>> still is a new CpuAVX10_1 bit, when I had asked to drop it. I'm also
>>>> concerned
>>>
>>> The reason is that we would like to keep the OR logic in the
>>> toolchain, which means opening AVX10.1 but closing AVX512F should not
>> disable the encoding.
>>>
>>> But I just double think on that and get your point. GCC is using a default "off"
>>> mode, if we are using OR logic, no code and current behavior are
>>> changed and everything is natural and smooth. However, binutils is using a
>> default "on"
>>> mode, if we stick to OR logic just like GCC, it will eventually
>>> corrupt the current behavior of .noavx512xxx, which could be a
>>> problem. I am slightly persuaded on the proposal of setting and clearing bits
>> of AVX512 for AVX10 in binutils.
>>
>> The primary indication of things being done the wrong way is the need to add
>> several ".arch .noavx10.1" in the testsuite. Whatever the final solution, this
>> should not be necessary (because it indicates people may also need to change
>> their code then, if they want a guarantee that no 512-bit insns are used).
>>
> 
> I have an open after digging into .arch directives corner cases when we choose
> to set/clear bits for AVX512 in AVX10.1.
> 
> Should directives like .noavx512f .avx10.1 open zmm registers?

You mean the combination of the two, in that order? Yes, of course.

> For directive
> .noavx512fp16 .avx10.1, should we enable zmm registers for AVX512FP16 insts?

And then yes here, too.

In both cases what remains to be determined is how vector size is to
be limited. I think that wants to be independent of the .avx10.<N>.

>>>> of CpuAVX10_MAX_512BIT, when I did suggest a new attribute (i.e. a
>>>> new bitfield in struct i386_opcode_modifier), and then a more general
>>>> purpose one (so that by it being / becoming not just boolean it can
>>>> later also be used to deal with the - for now only theoretical - AVX10/128
>> case).
>>>
>>> For question 2, I misunderstood the meaning of attribute. But I
>>> suppose
>>> AVX10/128 is too theoretical to be true. I will make it a boolean for now.
>>
>> Right, a boolean is fine initially, but with the spec explicitly allowing the 128-
>> bits-only mode, I'm pretty sure we ought to support that rather sooner than
>> later. After all, more artificial environments (emulators,
>> virtualization) may expose feature combinations not ever seen on real
>> hardware.
> 
> 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.

Jan