Add CMakePresets for target micro arch

[AntoinePrv]

I've taken the direction of explicit flags such as -mavx -mno-avx2.
This is IMHO less error prone and more accurate that using architecture name such as haswell.
The main difference is that this does not add other feature flags or change the -mtune model.
For a test setting accuracy is more important IMHO.

[serge-sans-paille]

I really like your approach and will eagerly merge it once it validates \o/

[AntoinePrv]

I've only kept the micro architecture target in CMakePresets.txt because combining with (debug/release) / (xtl on/off)... results in a combinatorial explosion of presets for which there is currently no support.
Another shortcoming is that we cannot dispatch here based on compiler for MSVC flags. We can do it based on OS but it is not quite the same.

I have ongoing work to actually do the same as these presets at the CMake level, with a function that can be made available to users to help in the tooling for dynamic dispatch (our current solution in Arrow is very verbose).
In this case, we'd need to also define a safe -march baseline. The reason is the code in these translation units might also include non SIMD code (this is sometimes the case in Arrow). In this case, with very advanced instruction sets, we're leaving perf on the table by having a x86-64 baseline. But what should be a reasonable baseline for dynamic dispatching to for example avx2?

• haswell (first avx2) also has fma3 and bmi2
• -march=haswell -mno-fma3 -mno-bmi2 if that is a thing?
• Or go further back? sandybridge (first avx)? nehalem (first sse4.2)

[AntoinePrv]

@serge-sans-paille this is in a ready state, but I am not fully happy with it.

Getting into AVX512, and AVX512-256, the combinatorial explosion of possibilities start to show again.
Inheritance of flags from other settings is also not possible.

This reinforce my belief that I should keep on with the work to do it in CMake (that could also be installed for our users to improve our dynamic dispatch tooling), and also homogenized with the test TARGET_ARCH var.

This PR is not completely worthless though. For example we now have the possibility to really test with avx512f, which was not the case before because no Intel arch is limited to the f feature only.

What do you think? Should we give this some mileage before I get the time to work on a CMake solution?

[serge-sans-paille]

!!!

[AntoinePrv]

Yes, there is a weird mismatch in master. Both CXX_FLAGS and CXXFLAGS where set but only CXX_FLAGS was explicitly passed to CMake. CXXFLAGS is picked up automatically but it was not exported.

[serge-sans-paille]

we sometime have fallback from avx2 instructions to sse instructions. How can this work??

[serge-sans-paille]

I do understand the need to prune higher instruction sets, but not the need to prune lower ones, please explain.

[AntoinePrv]

Do you mean -mno-sse4a ? This can be removed, I added when trying to debug some -march=native that was added by the absence of TARGET_ARCH.

Though it is not a problem here: sse4a is an AMD extension that was never implemented on Intel (and that is why it was failing in SDE).

[serge-sans-paille]

All looks good, except the question on pruning lower architectures which raises a big unknown to me.