PERF: Enable FFTW SIMD codelets with per-CPU introspection at configure time

[hjmjohnson]

Summary

• Add per-CPU SIMD detection at CMake configure time for FFTW external project builds
• Replace hardcoded ENABLE_*:BOOL=OFF flags with auto-detected, user-overridable cache options
• Forward all five SIMD flags (NEON, SSE, SSE2, AVX, AVX2) consistently to both fftwf and fftwd ExternalProject blocks

Detection Policy

Scenario	Detection	Result
Native ARM64 (aarch64/arm64/ARM64)	Architecture pattern	NEON=ON
Native x86_64 with GCC/Clang	CheckCSourceRuns + __builtin_cpu_supports()	Per-CPU SSE/SSE2/AVX/AVX2
Native x86_64 with MSVC	Probes skipped (intrinsic unavailable)	All SIMD OFF (user can override)
Cross-compile ARM64	Architecture pattern	NEON=ON
Cross-compile x86_64	Conservative	SSE+SSE2 only
Other architectures	—	All SIMD OFF

Every flag is individually overridable: cmake -DFFTW_ENABLE_AVX2=OFF ...

Relationship to PR #6004

This is the ITK v6 (main branch) forward-port of #6004, which targets release-5.4. Includes all review fixes from #6004:

• ARM64 (all-caps) added to regex for Windows ARM64 compatibility
• __builtin_cpu_supports probes guarded by compiler-ID check (GCC/Clang/AppleClang) to avoid noisy failures on MSVC
• ENABLE_SSE included in documentation comment

Test plan

• CI builds pass (FFTW is not enabled in CI, so this is a no-op for CI)
• Local build with -DITK_USE_FFTWF=ON on x86_64 Linux confirms SSE2/AVX2 detection
• Local build on Apple M4 confirms NEON=ON

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This PR replaces the previous hardcoded ENABLE_*=OFF flags in FFTW's ExternalProject_Add calls with auto-detected, user-overridable FFTW_ENABLE_* cache options. Detection uses CheckCSourceRuns with __builtin_cpu_supports() for GCC/Clang on x86/x86_64 (correctly gated off MSVC) and an architecture-pattern match for ARM64/AArch64 NEON, with a conservative cross-compile fallback. The five flags are consistently forwarded to both fftwf and fftwd ExternalProject blocks.

Confidence Score: 5/5

Safe to merge; detection logic is correct and all remaining findings are minor P2 suggestions.

The SIMD detection is correctly guarded for cross-compilation, MSVC, and non-x86/non-ARM architectures. The CheckCSourceRuns probes use proper CMake caching. The option() defaults are well-documented. Both remaining comments are P2 (stale-cache UX note and a harmless no-op SSE flag on fftwd), neither of which affects correctness or build reliability.

No files require special attention; only minor P2 style items remain.

Important Files Changed

Filename	Overview
CMake/itkExternal_FFTW.cmake	Adds per-CPU SIMD detection for FFTW ExternalProject builds: introduces CheckCSourceRuns probes for x86 SIMD levels (SSE/SSE2/AVX/AVX2) and architecture-based NEON detection, exposes five FFTW_ENABLE_* cache options, and forwards them to both fftwf and fftwd ExternalProject blocks.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[cmake configure] --> B{ITK_USE_SYSTEM_FFTW?}
    B -- yes --> Z[find_package FFTW]
    B -- no --> C{CMAKE_CROSSCOMPILING?}

    C -- no --> D{CMAKE_SYSTEM_PROCESSOR}
    D -- aarch64/arm64/ARM64 --> E[_fftw_default_neon = ON]
    D -- x86_64/AMD64/i686 --> F{C compiler = GCC/Clang/AppleClang?}
    F -- yes --> G[check_c_source_runs per SIMD level\nsse / sse2 / avx / avx2]
    G --> H[_fftw_default_* = ON if probe passes]
    F -- no MSVC --> I[all _fftw_default_* = OFF]
    D -- other --> I

    C -- yes --> J{CMAKE_SYSTEM_PROCESSOR}
    J -- aarch64/arm64/ARM64 --> K[_fftw_default_neon = ON]
    J -- x86_64/AMD64 --> L[_fftw_default_sse = ON\n_fftw_default_sse2 = ON]
    J -- other --> M[all _fftw_default_* = OFF]

    E & H & I & K & L & M --> N[option FFTW_ENABLE_NEON/SSE/SSE2/AVX/AVX2\ndefault = detected value\ncached — user-overridable]

    N --> O{ITK_USE_FFTWF?}
    O -- yes --> P[ExternalProject_Add fftwf\nENABLE_FLOAT=ON\n+ all FFTW_ENABLE_* flags]

    N --> Q{ITK_USE_FFTWD?}
    Q -- yes --> R[ExternalProject_Add fftwd\nENABLE_FLOAT=OFF\n+ all FFTW_ENABLE_* flags]

Loading

_{Reviews (1): Last reviewed commit: "PERF: Enable FFTW SIMD codelets with per..." | Re-trigger Greptile}

[hjmjohnson]

CI does not test FFTW

The following tests passed:
	itkFFTWF_FFTTest
	itkFFTWF_RealFFTTest
	itkVnlFFTWF_FFTTest
	itkVnlFFTWF_RealFFTTest
	itkFFTWD_FFTTest
	itkFFTWD_RealFFTTest
	itkVnlFFTWD_FFTTest
	itkVnlFFTWD_RealFFTTest
	itkFFTWComplexToComplexFFTImageFilter2DFloatTest
	itkFFTWComplexToComplexFFTImageFilter3DFloatTest
	itkFFTWComplexToComplexFFTImageFilter2DDoubleTest
	itkFFTWComplexToComplexFFTImageFilter3DDoubleTest
	itkFFTWForward1DFFTImageFilterTest
	itkFFTWInverse1DFFTImageFilterTest
	itkFFTWComplexToComplex1DFFTImageFilterTest
	itkFFTW1DImageFilterTest

100% tests passed, 0 tests failed out of 16

[hjmjohnson]

@dzenanz These are updates for the main branch followup to #6004 for the release-5.4 branch

[dzenanz]

We should enable FFTW in some CI build.

[seanm]

Configure-time checking of such things usually does not play well with 'universal binaries' on macOS (where one builds for both arm & intel)...

[hjmjohnson]

Configure-time checking of such things usually does not play well with 'universal binaries' on macOS (where one builds for both arm & intel)...

@seanm The defaults can be overridden. The default is to use no optimization, and in that case FFTW is at least 7.5 times slower, and often 10 times slower. FFTW becomes nearly useless in these cases.

The behavior is intended to default to no optimization if "CROSS_COMPLING" is on, and Ithink that is the case for universal binaries.

Do you have a recommendation for an alternative strategy?

Do we need something more than 886494b#diff-c55dd1b7b03f8f37a8d66eb87317f3aaf58d457eb7adea1aab4fd5d69a95ab1fR90.

[seanm]

"...each of SSE, SSE2, AVX, AVX2 is probed individually via __builtin_cpu_supports..." so even on non-Mac this strategy is dangerous, because it assumes that the machine building the code is the same as the machine running the code. If I'm making a Windows app and my buildbot is a beefy modern CPU but I still want customers with old CPUs to run the app, the app will presumably crash for them because it's using new CPU instructions that their old CPUs don't support.

Do you have a recommendation for an alternative strategy?

Compile-time checks.

#if defined(__SSE2__) && __SSE2__
  something1
#elif defined(__arm64__)
  something2
#elif defined(__x86_64__)
  something3
#elif etc.

(because the compiler knows what CPU it's compiling for)

[hjmjohnson]

@seanm These are the defaults for the most common use cases. In the less common scenario you define, one simply needs to explicitly turn them off. Once off, they stay off on subsequent cmake configurations, unless explicitly requested to be turned back on.

cmake -DENABLE_SSE:BOOL=OFF -DENABLE_NEON:BOOL=OFF ....

That is the primary reason for using option() rather than set() for these variables.

[seanm]

In the less common scenario you define...

Not so sure the scenario I described is "less common". I suspect most programmers have better CPUs than the customers running their code.

Anyway, I don't use FFTW so I don't much care in this case.