[compute/cker] Introduce compile-time definitions file

[tomdol]

This commit introduces a modern C++ version of compile-time features detection utilities. The advantage of this approach over using #ifdef is mostly safety which C++ itself provides. The main idea for the usage of those checks is with if constexpr and in the context of SFINAE.

ONE-DCO-1.0-Signed-off-by: Tomasz Dolbniak [email protected]

[tomdol]

This PR is just for demonstration purposes. I'd like to ask for an opinion if a set of such utilities would make sense here.

In my opinion it could simplify some of the code, provide more safety than #ifdefs and would make the code a bit more readable in some cases. The file Common.h was modified just to demonstrate how those traits could be used in the context of a template function where only one branch of the constexpr if is compiled depending on the target architecture.

[glistening]

Thank you for your suggestion. It is interesting.

However, personally I don't feel benefit this modern c++ compile-time, it is verbose and not intuitive like the classic one. I can't find what safety error modern c++ style can detect more. Could you please let me know the example if any?

Also, I guess the modern style is not friendly to IDE syntax highlighting.

In addition, we need to keep one more type of template correspondences on top of the existing macro. It will add maintenance cost.

[tomdol]

The non-preprocessor syntax is indeed more verbose but it is more c++ish way of checking things at compile time(just like it's done with https://en.cppreference.com/w/cpp/header/type_traits utilities). It's also more safe in the meaning that both the traits and their usages need to be a compilable, correct C++ while defines and preprocessor usage overall do not provide any safety checks. Thus anything can be used as a "value" of a define and as long as it can implicitly be cast to bool it will work whenever they are used in #ifdef or if statements.

The idea is related to this PR #14238 and to the branching in the ops implementations. Right now the runtime code is intermixed with preprocessor statements switching blocks of code on and off depending on the target architecture. I personally think it would be better to have a clear separation of paths so either separate functions containing target-specific intrinsics or separate if constexpr branches which would compile separately depending on the arch.

This is still just a loose suggestion though and an ask for opinion if this kind of changes would be acceptable in the cker module.

Lastly regarding the syntax highlighting I actually think the if constexpr approach is better because it doesn't make any part of the code "grayed out". Here's what I mean:

[glistening]

Thank you for answer. I would like to hear other's opinions also.

In addition, for IDE, I mean that I can turn on/off the code blocks by defining some macro definition. But I am not sure it is possible in modern c++ template approach. It is the reason it may not be IDE-friendly.