[PATCH] x86: emit warnings to avoid potential encoding surprises

[Jan Beulich]

On 17.08.2026 07:55, Jiang, Haochen wrote:
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Friday, August 14, 2026 9:22 PM
>>
>> FMA and F16C insns have direct AVX512VL counterparts. If the respective of
>> the two features is disabled, we'd silently fall back to the corresponding
>> EVEX encoding, which may not be intended by the user (their code may, for
>> example, not be AVX512-aware at all). See also [1], [2].
>>
>> A similar situation exists for the various VNNI extensions, where silently
>> falling back to later introduced forms may not be intended.
>>
>> A similar situation also exists for CRC32, the APX form of which requires
>> no 2nd ("base") feature.
>>
>> Using appropriate pseudo-prefixes will silence the warnings, as would
>> explicitly enabling the newer ISA extensions.
>>
>> Note that this in particular won't affect gcc, as that doesn't use .arch
>> directives on x86.
>>
>> [1] https://sourceware.org/pipermail/binutils/2026-July/150330.html
>> [2] https://sourceware.org/pipermail/binutils/2026-July/150334.html
>> ---
>> The testcase points out a possible anomaly: Despite the use of {vex}, EVEX
>> encodings are emitted for (originally) FMA and F16C insns when
>> ".arch .no*" is in use.
>>
>> The VNNI and CRC32 checks don't really need to live in install_template(),
>> yet I thought it would be better if related logic lived reasonably close
>> together.
> 
> It is what we could do the most per ISA-wise and LGTM.

Thanks for taking a look. In the end I think I'm most worried of CRC32:
Someone using ".arch .nosse" or alike may not at all be immediately aware
that this way all CRC32 uses will end up EVEX-encoded (in 64-bit code,
that is).

Jan