RE: [PATCH] x86: emit warnings to avoid potential encoding surprises
"Jiang, Haochen" <[email protected]>
| Newsgroups | gmane.comp.gnu.binutils |
|---|---|
| Message-ID | <SJ5PPF77D28E3C29B3BC854D4C0CDA3CC15ECA72@SJ5PPF77D28E3C2.namprd11.prod.outlook.com> |
> From: Jan Beulich <[email protected]> > Sent: Monday, August 17, 2026 2:30 PM > > On 17.08.2026 07:55, Jiang, Haochen wrote: > >> From: Jan Beulich <[email protected]> > >> 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). This is rather a taste in coding, where we should whether fully obey documentation or "predict" user expectation here for CRC32. At least obeying the documentation allows us having the evidence to tell users why this is happening. Thx, Haochen