RE: [PATCH v2] Support Intel AVX10.1

["Jiang, Haochen" <haochen.jiang@intel.com>]

> -----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? For directive
.noavx512fp16 .avx10.1, should we enable zmm registers for AVX512FP16 insts?

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

Thx,
Haochen

> 
> Jan