[PATCH v2] Support Intel AVX10.1

[Jiang, Haochen]

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

H.J., what is your opinion?

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

Thx,
Haochen

> 
> Jan