Add PF_ARM_V82_FHM and PF_ARM_V83_FCMA to PROCESSOR_FEATURE_ID / IsProcessorFeaturePresent

[lilith]

Request

Please add two new PF_ARM_* constants to the IsProcessorFeaturePresent API surface and the PROCESSOR_FEATURE_ID metadata enum:

• PF_ARM_V82_FHM — FEAT_FHM, FP16 Fused Multiply Add (FMLAL/FMLSL), ARMv8.4 mandatory
• PF_ARM_V83_FCMA — FEAT_FCMA, Floating-point Complex Multiply Add (FCMLA/FCADD), ARMv8.3 mandatory

Why these two specifically

Both are mandatory on every Windows-on-ARM CPU shipped to date (Microsoft SQ1/SQ2/SQ3, Snapdragon 8cx Gen 1/2/3, Snapdragon X Elite/Plus). There is no Windows ARM64 device in the field that lacks them, yet user-mode code currently has no Win32 way to confirm their presence — every other feature at comparable architecture level is now exposed.

The recent expansion in MicrosoftDocs/sdk-api#2140 (Dec 2025) added 30+ `PF_ARM_*` constants spanning SVE, SVE2, SME, SME2, SHA3, SHA512, `PF_ARM_V82_FP16`, `PF_ARM_V82_I8MM`, `PF_ARM_V86_BF16`, etc. FHM and FCMA were the conspicuous omissions in an otherwise thorough sweep.

Architectural inference doesn't fill the gap

Unlike FEAT_RDM — which can be inferred from FEAT_DotProd or FEAT_LSE via the ARMv8.1 AdvSIMD rule (Arm doc 109697, "The Armv8.1 architecture extension") and is what .NET 10 ships in dotnet/runtime#109493 — there is no equivalent direct architectural implication for FHM or FCMA from any IPFP-visible feature. The closest provable chain (via JSCVT or LRCPC pinning the v8.3-A floor) reaches FCMA but never FHM. Without these two constants, user-mode code on Windows ARM64 must fall back to reading `HKLM\HARDWARE\DESCRIPTION\System\CentralProcessor\0\CP ` registry values — workable, but registry access is not always available to sandboxed processes.

Downstream demand

• Rust's `is_aarch64_feature_detected!("fhm")` and `("fcma")` currently return `false` on Windows ARM64. Recently merged std_detect: support detecting more features on aarch64 Windows rust-lang/rust#155856 deliberately scoped its IPFP wiring to features Microsoft already exposes; FHM and FCMA were left out for that reason.
• .NET tracking of similar gaps: Arm64: RCPC, DC ZVA and probably RDM ISAs are never detected on win-arm64 dotnet/runtime#74778 (resolved once Microsoft added LRCPC/DC ZVA constants), [win-arm64] Update EEJitManager::SetCpuInfo in codeman.cpp to support ARMv8.1-RDMA and ARMv8.2-DotProd dotnet/runtime#39094, Enable Arm64 RDM on Windows dotnet/runtime#109493.
• Crypto libraries, image codecs, and signal-processing crates that already use FCMA on Linux/macOS ARM64 lose the codepath on Windows.

Precedent

#1618 covered the `PROCESSOR_FEATURE_ID` metadata enum lagging the SDK headers. This request is upstream of that — both the SDK header (`winnt.h`) and the metadata enum need the two new values.

[lilith]

Full wishlist — every stdarch AArch64 feature still unreachable via IPFP

While I'm here, the full set of is_aarch64_feature_detected! names that have no PF_ARM_* mapping today, grouped by use case. Most are already detectable via HKLM\...\CentralProcessor\0\CP <hex> registry values, but a Win32 API surface would let sandboxed processes (AppContainer, packaged apps, browser renderers) detect them too. Architecture revision noted where mandatory.

SIMD / compute (hottest for codec, DSP, and ML workloads)

• PF_ARM_V85_FRINTTS — FEAT_FRINTTS, FP-to-int rounding (ARMv8.5 mandatory)
• PF_ARM_SM4 — FEAT_SM4 (AdvSIMD form). PF_ARM_SVE_SM4 already exists for the SVE form.
• PF_ARM_LUT — FEAT_LUT, vector table lookup (Armv9.5)
• PF_ARM_FAMINMAX — FEAT_FAMINMAX, vector fp absolute min/max (Armv9.5)
• PF_ARM_FP8 / PF_ARM_FP8DOT2 / PF_ARM_FP8DOT4 / PF_ARM_FP8FMA — FEAT_FP8 family (Armv9.5)
• PF_ARM_FPMR — FEAT_FPMR, FPMR system register (Armv9.5)

Atomics / memory ordering

• PF_ARM_LSE128 — FEAT_LSE128, 128-bit atomics (Armv9.4)
• PF_ARM_V84_LRCPC2 — FEAT_LRCPC2 (Armv8.4 mandatory). Cumulatively encoded in ID_AA64ISAR1_EL1.LRCPC so detection is provable from registry, but no Win32 constant.
• PF_ARM_LRCPC3 — FEAT_LRCPC3 (Armv8.9)

Codegen / branch optimization

• PF_ARM_V88_MOPS — FEAT_MOPS, memcpy/memset instructions (ARMv8.8 mandatory). High value: enables compiler memcpy/memset codegen.
• PF_ARM_V84_FLAGM — FEAT_FlagM (ARMv8.4 mandatory)
• PF_ARM_V85_FLAGM2 — FEAT_FlagM2 (ARMv8.5 mandatory)
• PF_ARM_V89_CSSC — FEAT_CSSC, popcount/abs short sequences (ARMv8.9 mandatory)
• PF_ARM_V88_HBC — FEAT_HBC, hinted conditional branches (ARMv8.8 mandatory)

Cache / persistent memory

• PF_ARM_V82_DPB — FEAT_DPB, DC CVAP (ARMv8.2 mandatory). Conspicuous omission given V82_FP16 / V82_I8MM / V82_LSE2 are all present.
• PF_ARM_V85_DPB2 — FEAT_DPB2, DC CVADP (ARMv8.5 mandatory)

RNG

• PF_ARM_V85_RAND — FEAT_RNG, RNDR/RNDRRS (ARMv8.5 optional). Useful for libraries that want hardware entropy without BCryptGenRandom overhead.

Security / hardening

• PF_ARM_V83_PACA — FEAT_PAuth (ARMv8.3 mandatory). Currently unobservable from user-mode despite being mandatory.
• PF_ARM_V83_PACG — FEAT_PAuth generic
• PF_ARM_V89_PAUTH_LR — FEAT_PAuth_LR (ARMv8.9)
• PF_ARM_V85_BTI — FEAT_BTI (ARMv8.5 mandatory)
• PF_ARM_V85_MTE — FEAT_MTE / MTE2 (ARMv8.5 optional)
• PF_ARM_V84_DIT — FEAT_DIT, data-independent timing (ARMv8.4 mandatory)
• PF_ARM_V85_SB — FEAT_SB, speculation barrier (ARMv8.5 mandatory)
• PF_ARM_V85_SSBS — FEAT_SSBS (ARMv8.5 mandatory)

System / power

• PF_ARM_V86_ECV — FEAT_ECV, enhanced counter virtualization (ARMv8.6 mandatory)
• PF_ARM_V87_WFXT — FEAT_WFxT, WFE/WFI with timeout (ARMv8.7 mandatory)
• PF_ARM_TME — FEAT_TME, transactional memory (note: removed from later Arm ARM revisions, but still in some encodings)

Tier ranking (if prioritization helps)

If you can only add a handful, the top-impact set for user-mode software in 2026 is:

1. PF_ARM_V82_FHM, PF_ARM_V83_FCMA (the main ask above) — codec/DSP/ML hot paths, already mandatory on every shipped WoA SoC.
2. PF_ARM_V88_MOPS — compiler memcpy/memset codegen on Snapdragon X+.
3. PF_ARM_V83_PACA, PF_ARM_V83_PACG, PF_ARM_V85_BTI — security hardening detection for hardened runtimes.
4. PF_ARM_V82_DPB, PF_ARM_V85_DPB2 — persistent memory / cache management.
5. PF_ARM_V85_RAND — entropy without crypto API roundtrip.

Everything else is nice-to-have. The naming convention in this comment follows the existing PF_ARM_V<major><minor>_<NAME> pattern (PF_ARM_V81_ATOMIC, PF_ARM_V82_FP16, PF_ARM_V83_LRCPC, PF_ARM_V86_BF16) — Microsoft is free to deviate; these are just suggestions.

Reference for the full feature list and detection-method classification: https://github.com/imazen/winarm-cpufeatures/blob/main/src/features.rs

[riverar]

Ping @jevansaks, think this is a SDK ask; @dpaoliello purely informational given recent arm64/amd64ec activity.