Select SIMD code from compiler target flags

[dimpase]

Summary

AX_EXT probes the build machine's CPU and adds SIMD flags based on that machine. Distribution and cross builds need the selected code path to follow the compiler target without appending machine-derived flags to CFLAGS.

Select AVX2 and AVX-512 code from the compiler target by default. Add --enable-avx2 and --enable-avx512f, so packagers can explicitly enable or disable either code path. An explicit enable checks that the compiler target supports the required intrinsics and fails at configure time with a clear message if it does not. The AVX-512 implementation requires both AVX-512F and AVX-512BW. The two options can be disabled independently, including AVX2 while retaining AVX-512.

This is compile-time selection; it does not add runtime CPU dispatch.

Validation

• Baseline CFLAGS='-O2 -pipe -march=x86-64': build and all 68 tests passed; neither SIMD implementation enabled.
• CFLAGS='-O2 -pipe -mavx2': build and all 68 tests passed with AVX2 enabled.
• CFLAGS='-O2 -pipe -mavx2' --disable-avx2: build and all 68 tests passed with both SIMD implementations disabled.
• CFLAGS='-O2 -pipe -mavx512f -mavx512bw' --disable-avx2 --enable-avx512f: build passed with AVX-512 enabled and AVX2 disabled. The binary was not run because this host lacks AVX-512.
• CFLAGS='-O2 -pipe -mavx512f' fails during configure with an AVX-512BW requirement message; --disable-avx512f allows that target.
• --enable-avx2 with a baseline x86-64 compiler target fails during configure with an AVX2 requirement message.
• Baseline make distcheck passed before the option follow-up.

Signed-off-by: Dima Pasechnik dima@pasechnik.info

AI assistance: Codex helped prepare and validate this change.

[dimpase]

@mohabsafey - This should make life much easier for distributions. The normally don't want arch-dependent flags of the build host to leak into binaries they build - something that potentially leads to annoying runtime errors.
Instead, this makes the compiler and other tools' settings the default.

You can still build using the host arch, by passing -march=native to ./configure.

[dimpase]

You may wonder why one CI run on this PR is failing - this is reproducible with the random seed of that very run, namely:

SEED=1790795968 bash test/diff/diff_cyclic5-16.sh

fails both ways, with and without this PR branch.

[dimpase]

@orlitzky - this came from an attempt to make a Gentoo ebuild for msolve.

[orlitzky]

This is an improvement as-is (we don't want machine CFLAGS added by surprise), but I would go one step further and disconnect the machine-specific code from the compiler's optimization flags. The macros like __AVX2__ are only defined when e.g. -mavx2 is in the user's CFLAGS... they are a good guess, but occasionally it is nice to be able to switch off the optimizations without the code, or the other way around.

Gentoo has USE flags for these (cpu_flags_x86_avx2 and cpu_flags_x86_avx512f) that end users will typically enable on machines that support them, but can be disabled for whatever weird reasons. This is independent from CFLAGS which we try to leave alone / ignore.

The best solution from that perspective would be,

• Don't append any CFLAGS at all (already done in this PR)
• Add --enable-avx2 and --enable-avx512f flags to ./configure that default to on if __AVX2__ and __AVX512F__ are defined, but can be overridden with --disable-<flag>.

[dimpase]

@orlitzky - like this?

[orlitzky]

@orlitzky - like this?

Yeah, thanks. It looks like avx512bw was also being included under the umbrella of avx512f? I don't have a new enough processor to confirm, but if so, we have a separate USE flag for avx512bw.

It would also be nice to have an AC_MSG_CHECKING ... AC_MSG_RESULT pair when the options are set to "auto" :)

[orlitzky]

The intel docs say that _mm256_mullo_epi16 and _mm512_mullo_epi16 are part of avx512bw and I see that they're used in some but not all of the same places as the other avx512f stuff is. The least effort solution at the moment is probably to,

1. Add --enable-avx512bw like the others and define HAVE_AVX512_BW.
2. In the functions where both are needed, change the preprocessor conditionals to HAVE_AVX512_F && HAVE_AVX512_BW.
3. Anywhere else, leave alone.

In the future, someone could improve the granularity by adding fallback C multiplication for the few avx512bw instructions, allowing people with avx512f but not avx512bw to reap most of the benefits.

[orlitzky]

(And I think m4/ax_ext.m4 and m4/ax_gcc_x86_avx_xgetbv.m4 become redundant afterwards.)

I see that there's an issue (#71) and draft PR (#376) for runtime detection. I don't think this necessarily conflicts, we would just limit runtime detection to the "auto" case. Being able to disable the intrinsics is independently useful, and in the easy case (building for your own machine) it would remain much simpler to just enable them.