Defines `SIMSIMD_CAN_COMPILE_F16` and `SIMSIMD_CAN_COMPILE_BF16` unused?

[rschu1ze]

I find this in CMakeLists.txt

# Check for `__fp16` support
check_c_source_compiles(
    [=[
int
main(int argc, char *argv)
{
  __fp16 a = 1.0;
  __fp16 b = a + a;
  return 0;
}
]=]
    SIMSIMD_CAN_COMPILE_F16
)

# Check for `__bf16` support
check_c_source_compiles(
    [=[
int
main(int argc, char *argv)
{
  __bf16 a = 1.0;
  __bf16 b = a + a;
  return 0;
}
]=]
    SIMSIMD_CAN_COMPILE_BF16
)

if (SIMSIMD_CAN_COMPILE_BF16)
    add_compile_definitions(SIMSIMD_CAN_COMPILE_F16)
    add_compile_definitions(SIMSIMD_CAN_COMPILE_BF16)
endif ()

but defines SIMSIMD_CAN_COMPILE_F16 and SIMSIMD_CAN_COMPILE_BF16 are nowhere else used in the repository. Is this a leftover?

[ashvardanian]

Let's call it a work in progress, @rschu1ze 😄 In Rust I try compiling with different configs until one of the passes. In C/C++ we should probably use those value to infer if the native f16/bf16 implementation should be used, or if they should be emulated. But the CMake has to be extended to also include _Float16, that some compilers support.

[ashvardanian]

If you have a patch in mind, please feel free to submit a PR 🤗

[rschu1ze]

Well, it I had to decide, I'd keep the detection logic for compiler-specific types __fp16 and _bf16 as is, and instead wait for the new float types introduced with C++23. They made them (unfortunately) optional, and (also unfortunately) Clang doesn't provide them yet (here, P1467R9). At least they will be standardized across compilers and they will come with feature detection macros that can be used in the source code.

Anyways, perhaps C++23 is too aggressive for simsimd. I'd be good with closing this issue.