Re: [PATCH 2/2] x86: fold F16C templates with their AVX512VL counterparts

On 21.07.2026 05:16, Jiang, Haochen wrote:
>> From: Jan Beulich <[email protected]>
>> Sent: Friday, July 17, 2026 9:50 PM
>>
>> This actually points out another issue with FMA and F16C: Code created
>> prior to the introduction of AVX512 might have used ".arch .no{fma,f16c}"
>> to have uses of the respective insns properly rejected. That protection
>> suddenly ceased to work properly when AVX512 support was added to the
>> assembler: Those insns would now assemble to their AVX512VL EVEX forms.
>> The least bad option to deal with this looks to be to reject the AVX512VL
>> forms also when FMA/F16C are explicitly disabled while AVX512VL isn't
>> explicitly enabled. Are there any better suggestions?
> 
> When enabling AVX512VL, those EVEX forms should be enabled since it
> is an "or" claimed in SDM. It is a bug but just not reported.

Here pretty prominently, but also elsewhere below I can't resolve ambiguities
in your reply. On one hand I'm getting the impression that you want us to
follow what the SDM mandates, while otoh ...

> The behavior
> is the same in GCC, where -mno-fma will not control EVEX version. The
> actual flag to totally disable FMA is -ffp-contract=off.
> 
> So, I believe we should just enable those insts under this scenario. The
> thing we might need to do is to add a mandatory EVEX prefix here, but
> maybe tricky.
> 
> Ref from GCC repo in gcc/config/i386/sse.md, which actually applied
> to all FMA, but it is mentioned in scalar part:
> 
> ;; The standard names for scalar FMA are only available with SSE math enabled.
> ;; CPUID bit AVX512F enables evex encoded scalar and 512-bit fma.  It doesn't
> ;; care about FMA bit, so we enable fma for TARGET_AVX512F even when TARGET_FMA
> ;; and TARGET_FMA4 are both false.
> ;; TODO: In theory AVX512F does not automatically imply FMA, and without FMA
> ;; one must force the EVEX encoding of the fma insns.  Ideally we'd improve
> ;; GAS to allow proper prefix selection.  However, for the moment all hardware
> ;; that supports AVX512F also supports FMA so we can ignore this for now.

... you quote this. If we followed this (and then also for F16C, which in gcc
doesn't have a similar comment but looks to be treated similarly).

So - are you suggesting to keep dependencies as we have them, or are you
suggesting to introduce "artificial" dependencies of AVX512F (or AVX512VL) on
FMA and F16C (thus allowing simplification here and perhaps elsewhere)? Or
yet something else?

Jan