diff mbox series

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

Message ID 00efa750-04fb-4e65-a0b7-81ab68986df5@suse.com
State New
Headers
Series x86: adjust AVX-VNNI-INT{8,16} prereqs |

Checks

Context Check Description
linaro-tcwg-bot/tcwg_binutils_build--master-arm success Build passed
linaro-tcwg-bot/tcwg_binutils_build--master-aarch64 success Build passed
linaro-tcwg-bot/tcwg_binutils_check--master-aarch64 success Test passed
linaro-tcwg-bot/tcwg_binutils_check--master-arm success Test passed

Commit Message

Jan Beulich Sept. 5, 2024, 11:32 a.m. UTC 
  These are more logical to take AVX-VNNI as prereq, retaining AVX2 as an
indirect prereq.
---
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.

Comments

Jiang, Haochen Sept. 6, 2024, 2:51 a.m. UTC | #1 
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Thursday, September 5, 2024 7:32 PM
> 
> These are more logical to take AVX-VNNI as prereq, retaining AVX2 as an
> indirect prereq.

From HW side, that is ok till now since I don't see a machine with
AVX-VNNI-INT{8,16} but no AVX-VNNI.

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.

BTW, maybe the .noxxx is the only blocking issue I could see currently for
the change.

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

Thx,
Haochen

> 
> --- a/opcodes/i386-gen.c
> +++ b/opcodes/i386-gen.c
> @@ -163,9 +163,9 @@ static const dependency isa_dependencies
>    { "AVX_IFMA",
>      "AVX2" },
>    { "AVX_VNNI_INT8",
> -    "AVX2" },
> +    "AVX_VNNI" },
>    { "AVX_VNNI_INT16",
> -    "AVX2" },
> +    "AVX_VNNI" },
>    { "AVX_NE_CONVERT",
>      "AVX2" },
>    { "CX16",
Jan Beulich Sept. 6, 2024, 6:24 a.m. UTC | #2 
On 06.09.2024 04:51, Jiang, Haochen wrote:
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Thursday, September 5, 2024 7:32 PM
>>
>> These are more logical to take AVX-VNNI as prereq, retaining AVX2 as an
>> indirect prereq.
> 
> From HW side, that is ok till now since I don't see a machine with
> AVX-VNNI-INT{8,16} but no AVX-VNNI.
> 
> 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.

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

Jan
Jiang, Haochen Sept. 6, 2024, 6:38 a.m. UTC | #3 
> 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
diff mbox series

Patch

--- a/opcodes/i386-gen.c
+++ b/opcodes/i386-gen.c
@@ -163,9 +163,9 @@  static const dependency isa_dependencies
   { "AVX_IFMA",
     "AVX2" },
   { "AVX_VNNI_INT8",
-    "AVX2" },
+    "AVX_VNNI" },
   { "AVX_VNNI_INT16",
-    "AVX2" },
+    "AVX_VNNI" },
   { "AVX_NE_CONVERT",
     "AVX2" },
   { "CX16",