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

[Jiang, Haochen]

> From: Jan Beulich <jbeulich@suse.com>
> 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. 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.

Thx,
Haochen