COMP: Decide the x86-64 microarchitecture baseline for distributed ITK packages (sibling of #6745)

[hjmjohnson]

Sibling of #6745. Both concern the ISA-level policy in CMake/ITKSetStandardCompilerFlags.cmake's check_compiler_optimization_flags() — #6745 asks how high the ceiling should go (-march=x86-64-v4 and whether -mprefer-vector-width=256 must accompany it); this asks where the floor should sit for redistributed packages. RHEL 9, Fedora, and SUSE all require x86-64-v2 of their packages; ITK currently emits no -march at all.

The question is sharper than "should we raise the floor," because 7c0bfe8654e (2026-04-13) removed -march=corei7 — which was roughly v2-equivalent — without replacing it. ITK's effective distribution baseline may have moved down, not held steady.

What the tree does today

check_compiler_optimization_flags() sets no architecture flags and says why:

# No architecture-specific optimization flags are set by default,
# ensuring maximum redistributability for pip wheels, Docker images,
# and hardware translation layers (Rosetta, QEMU).
# Users building for local performance should add -march=native via
# CMAKE_C_FLAGS/CMAKE_CXX_FLAGS or CMakeUserPresets.json.

This is a deliberate, documented position, not an oversight. The purpose of
this issue is to decide whether it is still the right one for distributed
binaries, or whether build-from-source and wheel/package builds should be
allowed to diverge.

What changed, and why "floor" is the right word

7c0bfe8654e — "COMP: Remove hardcoded -march=corei7, -mtune=generic, and dead code" (2026-04-13) removed:

-mtune=generic  # for reproducible results (#1939)
-march=corei7   # ABI settings to support corei7 (circa 2008 ABI feature sets)

corei7 (Nehalem, 2008) implies SSE4.2 / POPCNT / CMPXCHG16B — essentially
the x86-64-v2 feature set under a non-standard spelling. So ITK shipped
with ~v2 assumptions for years and now ships with none.

Whether that matters depends entirely on whether any redistributed artifact
was actually built through this code path. That is the first thing to
establish, and it is answerable rather than arguable.

Prior art — the abstraction was proposed and withdrawn

PR #6039 ("COMP: Replace hardcoded -march=corei7 with ITK_X86_64_ISA_LEVEL")
proposed a cache variable with options default / x86-64 / x86-64-v2 / x86-64-v3 / x86-64-v4 / native. It was closed 2026-04-13 in favour of simply
deleting the hardcoded flag, with the note that "the ISA level abstraction
can be revisited later if needed." This issue is that revisit.

The reasoning recorded at the time for defaulting to plain baseline rather
than v2:

• pip wheels, Docker images, and translation layers (Rosetta 2, QEMU) only
  guarantee baseline x86-64
• Fedora/RHEL 9 and SUSE use x86-64-v2 as a distro minimum
• users building locally for their own hardware should use -march=native

Proposed work

1. Establish the factual baseline first. Determine which redistributed
   artifacts (PyPI wheels, conda packages, Docker images) actually pass
   through check_compiler_optimization_flags(), and what -march each
   effectively compiles with today. Without this the rest is speculation.
2. Decide whether build-from-source and package builds should diverge.
   A distro-style x86-64-v2 floor for packages is compatible with keeping
   source builds at plain baseline; they need not share a default.
3. If a floor is adopted, decide the mechanism — reviving COMP: Replace hardcoded -march=corei7 with ITK_X86_64_ISA_LEVEL #6039's
   ITK_X86_64_ISA_LEVEL cache variable, or a narrower packaging-only
   setting — and document the guaranteed minimum explicitly, which ITK does
   not currently state anywhere.
4. Quantify before adopting. Any floor should be justified by measured
   benefit on ITK's own workloads, not by matching distro policy for its own
   sake. PERF: Quantify -mprefer-vector-width=256 as a required companion to -march=x86-64-v4 #6745's Resample sweep is the template, and its finding that
   -march=x86-64-v4 regresses BSpline by 12–17% is a direct warning that
   higher is not automatically better.

Counter-arguments that must survive

• Rosetta 2 / QEMU. Translation layers are the strongest argument for
  staying at baseline; a v2 floor could break x86-64 wheels under emulation.
• Nothing is obviously broken. No user report motivates this. The case is
  consistency-with-distros plus recovering the pre-7c0bfe8654e position,
  which is weaker than a defect report.
• The gain may be negligible. SSE4.2/POPCNT are unlikely to move ITK's
  memory-bound kernels much. See item 4 — this may resolve as "document the
  current baseline and close."

An entirely legitimate outcome is: confirm plain baseline is correct, state
it explicitly in the documentation, and close. The current situation —
no stated guarantee either way — is the part worth fixing regardless.