Home Original page

[PATCH 01/10] Support Intel AVX-IFMA

H.J. Lu hjl.tools@gmail.com
Wed Oct 19 21:27:11 GMT 2022 
On Tue, Oct 18, 2022 at 11:01 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 18.10.2022 23:28, H.J. Lu wrote:
> > On Mon, Oct 17, 2022 at 10:33 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 18.10.2022 00:23, H.J. Lu wrote:
> >>> On Sat, Oct 15, 2022 at 11:39 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> On 14.10.2022 20:10, H.J. Lu wrote:
> >>>>> On Fri, Oct 14, 2022 at 2:52 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>
> >>>>>> On 14.10.2022 11:12, Haochen Jiang wrote:
> >>>>>>> From: wwwhhhyyy <hongyu.wang@intel.com>
> >>>>>>>
> >>>>>>> x86: Support Intel AVX-IFMA
> >>>>>>>
> >>>>>>> Intel AVX IFMA instructions are marked with CpuVEX_PREFIX, which is
> >>>>>>> cleared by default.  Without {vex} pseudo prefix, Intel IFMA instructions
> >>>>>>> are encoded with EVEX prefix.  {vex} pseudo prefix will turn on VEX
> >>>>>>> encoding for Intel IFMA instructions.
> >>>>>>
> >>>>>> I firmly object to the proliferation of this mis-feature. As expressed
> >>>>>> before for AVX-VNNI, as long as the user has disabled AVX512 (or
> >>>>>> respective sub-features thereof), there should be no need to use {vex} in
> >>>>>> the source code. There's also no reason at all to make the disassembler
> >>>>>> print {vex} prefixes - we don't do so for any other insns (apart from
> >>>>>> AVX-VNNI) where an ambiguity exists between their VEX and EVEX encodings
> >>>>>> (when none of the EVEX-specific features is used).
> >>>>>
> >>>>> The {vex} prefix is used with AVX-IFMA instructions so that IFMA instructions
> >>>>> without a prefix, which are generated by compilers or handwritten, will be
> >>>>> always encoded with EVEX.
> >>>>
> >>>> So again: Why is this necessary when a programmer disabled AVX512? I fully
> >>>> agree we need to pick the EVEX encoding by default if available, but I see
> >>>> no reason whatsoever to insist on a {vex} prefix when the EVEX variant is
> >>>> unavailable anyway. As you said back at the time for AVX-VNNI - this was a
> >>>> design decision taken at Intel. Which is fine for a draft implementation.
> >>>> But decisions for an open source project should be taken in the open, and
> >>>> opinions of others should not simply be put off.
> >>>>
> >>>
> >>> We can discuss how to initialize i.vec_encoding.  But it is orthogonal to
> >>> this patch.
> >>
> >> One can view it as orthogonal, yes, but if we change the model then doing
> >> so before more code and testcases need changing is imo preferable.
> >>
> >
> > We can skip the pseudo VEX prefix check when AVX512F is disabled.
>
> Let me see if I can pull ahead the patch I have (right now it's at the end
> of the 3rd series I have pending, when the 1st one continues to be debated),
> so the new cases in this series could then come on top.

Something like this:

diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c
index 01f84cb9a36..a9fd3115659 100644
--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -6458,8 +6458,9 @@ match_template (char mnem_suffix)

       /* Check Pseudo Prefix.  */
       if (t->opcode_modifier.pseudovexprefix
+    && cpu_arch_flags.bitfield.cpuavx512f
     && !(i.vec_encoding == vex_encoding_vex
-        || i.vec_encoding == vex_encoding_vex3))
+         || i.vec_encoding == vex_encoding_vex3))
   continue;

       /* Check AT&T mnemonic.   */

It works on existing tests.

> > There should be no testcase changes.
>
> Well - existing tests ought it continue to work, yes, but the prefix-less
> forms then also will want testing.
>
> Jan



-- 
H.J.
More information about the Binutils mailing list