slvndx overflows its 12 bits

[jcelerier]

I'm hitting an issue in fftw-3.3.10 when calling fftw_plan_dft_r2c_1d, where slvndx in

static plan *search(planner *ego, const problem *p, unsigned *slvndx, 		    flags_t *flagsp)

gets computed to 4153 (> 4096) and thus overflows its 12-bit bitfield and triggers the check in planner.c:

     /* keep this check enabled in case we add so many solvers
	that the bitfield overflows */
     CK(SLVNDX(slot) == slvndx);    

I am building with:

CC=clang-19
CFLAGS=-O0 -g3

./configure  --enable-threads \
  --enable-fma \
  --enable-generic-simd128 \
  --enable-generic-simd256 \
  --enable-sse2 \
  --enable-avx \
  --enable-avx-128-fma \
  --enable-avx2 \
  --disable-fortran

If I remove some options, for instance:

CC=clang-19
CFLAGS=-O0 -g3

./configure  --enable-threads \
  --enable-fma \
  --enable-avx \
  --enable-avx-128-fma \
  --enable-avx2 \
  --disable-fortran

then the issue goes away (but then I guess my fftw will not work on older CPUs)

[stevengj]

Yikes, I didn't realize we had hit this point.

Fortunately, FFTW will still work on older CPUs, it just might not reach optimal performance on them. (FFTW automatically disables kernels that are not applicable to the current CPU.). But if you're using a on an ancient CPU, then probably performance is a tertiary concern for you (or alternatively you should compile an optimized FFTW binary for that CPU).

[rdolbeau]

I would advise against using 'generic' on any CPU with supported SIMD. They are here as a stopgap using gcc's own SIMD generic support for new architectures that have support in gcc but not (yet) fftw3.

On x86-64, you should probably only enable sse2/avx/avx2/avx-512. "avx-128-fma" is fairly specific performance-wise to some AMD design IIRC. enable-fma is unlikely to help and might degrade as FMA3 (the standard FMA) on x86-64 is 3-operands destructive. The FMA4 available on some older AMD cpu might make enable-fma useful (it is a true 4-operands FMA, but is only available on some specific models).

Also, getting an "optimal" fftw3 for multiple CPUs is nigh impossible. For instance, on modern CPU with AVX-512 support, forcing the compilation of FFTW3 with avx-512 support enabled in the compiler for all files (including the sse2, avx, avx2 codelets) should enable the compiler to use the additional SIMD registers available with avx-512 (or rather EVEX encoding, you can use 32 registers instead of 16 even with 128-bits xmm and 256-bits ymm registers), thus improving performance. However, such a library won't run on anything without AVX-512...