[PATCH] x86: adjust AVX-VNNI-INT{8,16} prereqs

[Jiang, Haochen]

> From: Jan Beulich <jbeulich@suse.com>
> Sent: Friday, September 6, 2024 2:24 PM
> 
> On 06.09.2024 04:51, Jiang, Haochen wrote:
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Thursday, September 5, 2024 7:32 PM
> >>
> > But this will lead to if someone uses .arch .noavx_vnni, then it will turn
> > of AVX-VNNI-INT{8,16}. I don't think this is the expected behavior. If we
> > care about this .noxxx behavior, we should not do that. This is not quite
> > same as the AVX10.2 I will mention next since IMO, these three ISAs
> > are quite independent.
> 
> But that's actually one of the points of the change: I _want_ .noavx_vnni
> to have said effect. It makes little sense to me to keep AVX-VNNI-INT{8,16}
> enabled when AVX-VNNI is off.

But AVX-VNNI-INT{8,16} have different signed type with AVX-VNNI. That is why
I suppose they should be independent. They should not be all controlled by
AVX-VNNI.

> 
> >> ---
> >> In turn the question arises whether AVX10.2 should consider both to be
> >> prereqs as well. The situation here isn't the same as it was with AVX512-VNNI
> >> vs AVX-VNNI, after all.
> >
> > For AVX10.2, maybe I would like to prefer to imply them since it is weird not
> > having VEX part when having EVEX part if the EVEX part is introduced after
> > VEX and there is no HW only having EVEX part. Although GCC will not do
> > the imply since we are pretty conservative on that and will stick to doc,
> > in Binutils, for convenience, I suppose it could be done.
> 
> And what are the chances of the doc being updated to mention all AVX-VNNI*
> as implied by AVX10.2, just like AVX10.1 documents a fair number of AVX512*
> as implied?
> 
> Similarly for the earlier remark, and more generally: It would help if the
> SDM specified dependencies between extensions more clearly / strictly than
> it does right now.

I once raised the similar question to documentation guy long ago (maybe 1.5yrs).

They are not willing to do that although I really disagree with them on this part.
Unfortunately, I could not find the exact mailing thread for that. In my dim memory
on that thread, they still want to keep the independence of these ISAs at least
in documentation.

Thx,
Haochen

> 
> Jan