Change portability flag

[baentsch]

Following up on this discussion this is to suggest renaming OQS_PORTABLE_BUILD to something like OQS_CPU_RT_EXTENSION_CHECK to avoid future confusion. This would also make it obvious that the combination OQS_USE_CPU_EXTENSIONS=OFF&&OQS_CPU_RT_EXTENSION_CHECK=ON is pointless.

Second, should we add CMAKE_BUILD_TYPES for "Reference" (a configuration permitting benchmarking of all algorithms' baseline, reference code. Build anywhere, run anywhere. Slow. No feature-test overhead) and "Performance" (A configuration permitting benchmarking of all algorithms' best optimized code. Build on CPUs with all required features, executing OK on CPUs with those features, crashing on CPUs without these features. No feature-test overhead) configs documenting what we "mean" by the config flags?

[jschanck]

My vote is to change "OQS_PORTABLE_BUILD" to "OQS_DISTRIBUTABLE_BUILD".

I'd also suggest removing the OQS_USE_CPU_EXTENSIONS boolean in favour of an "OQS_TARGET_ARCH" string. Setting OQS_TARGET_ARCH would force OQS_DISTRIBUTABLE_BUILD=OFF and would set "-march=OQS_TARGET_ARCH" in gcc_clang_intrinsics.cmake.

CMAKE_BUILD_TYPES can be used to provide sensible defaults, as @baentsch suggests.

• His "Reference" build is OQS_TARGET_ARCH=x86_64 (and something else on ARM, etc)
• His "Performance" build is OQS_TARGET_ARCH=native.

Advanced users can also hand pick an implementation. For instance, if there are ref, avx2, and avx512 implementations, and your machine supports AVX512 instructions, neither Reference nor Performance will select the avx2 implementation. You could still override the default by passing OQS_TARGET_ARCH=haswell.

[baentsch]

Thanks for the suggestions how to implement "Reference" and "Performance" builds: LGTM. What would be the configuration for the current "Release" and "Debug" build types under this proposal?

Additional questions to help me understand further:

I'd also suggest removing the OQS_USE_CPU_EXTENSIONS boolean in favour of an "OQS_TARGET_ARCH" string.

Does this mean we would do away with the runtime testing of CPU features entirely? Or how/when would those be enabled?

Setting OQS_TARGET_ARCH would force OQS_DISTRIBUTABLE_BUILD=OFF and would set "-march=OQS_TARGET_ARCH" in gcc_clang_intrinsics.cmake.

Do I understand right then that the only way to set OQS_DISTRIBUTABLE_BUILD=ON would be to leave OQS_TARGET_ARCH empty? Which architecture would that "distributable build" then target? How would we specify building, say ARM64 reference and ARM64 optimized builds?

[jschanck]

I'd also suggest removing the OQS_USE_CPU_EXTENSIONS boolean in favour of an "OQS_TARGET_ARCH" string.

Does this mean we would do away with the runtime testing of CPU features entirely? Or how/when would those be enabled?

No, OQS_DISTRIBUTABLE_BUILD (like the current OQS_PORTABLE_BUILD) would enable runtime testing of CPU features. The OQS_TARGET_ARCH option (like the current OQS_USE_CPU_EXTENSIONS option) would trigger a test in CMake that enables the the correct OQS_USE_X_EXTENSIONS flags for non-distributable builds.

Setting OQS_TARGET_ARCH would force OQS_DISTRIBUTABLE_BUILD=OFF and would set "-march=OQS_TARGET_ARCH" in gcc_clang_intrinsics.cmake.

Do I understand right then that the only way to set OQS_DISTRIBUTABLE_BUILD=ON would be to leave OQS_TARGET_ARCH empty? Which architecture would that "distributable build" then target? How would we specify building, say ARM64 reference and ARM64 optimized builds?

As with the current OQS_PORTABLE_BUILD, setting OQS_DISTRIBUTABLE_BUILD=ON would target x86_64 if you're on x86_64, or some fairly generic ARM CPU if you're on ARM. I suppose that OQS_TARGET_ARCH could accept a shorter list of "generic" architectures when OQS_DISTRIBUTABLE_BUILD=ON. This could be used for cross-compilation.

[baentsch]

I suppose that OQS_TARGET_ARCH could accept a shorter list of "generic" architectures when OQS_DISTRIBUTABLE_BUILD=ON.

Thanks! That surely would be better than

Setting OQS_TARGET_ARCH would force OQS_DISTRIBUTABLE_BUILD=OFF

Last remaining question:

What would be the configuration for the current "Release" and "Debug" build types under this proposal?

Alternatively to an answer here I'd be glad to review a PR. Thanks again for the proposal and explanations.