[PATCH 01/10] Support Intel AVX-IFMA

[Jan Beulich]

On 19.10.2022 23:27, H.J. Lu wrote:
> 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.

But adds code rather than removing some (with the same effect). I see
you've approved my patch doing the latter, so I'll put it in. The new
ISA extensions then will want to follow suit. I also have the {evex}
disassembler patch mostly ready, but I'd like to, at the same time,
address testsuite anomalies that I've spotted along the road.

Jan