Re: [PATCH v2] Support Intel AVX10.1

[Jan Beulich <jbeulich@suse.com>]

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

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

Jan