[SYCL][CUDA] Add SM version check to bfloat16 CUDA test

[steffenlarsen]

bfloat16 requires SM80 on the CUDA backend. This commit changes CUDA tests to do an early exit if that requirement is not met.

[JackAKirk]

So bfloat16 doesn't require SM80 on the CUDA backend since intel/llvm#6524. I wrote in #6524 that we should now remove the bfloat16_type_cuda.cpp test, since the only difference is that it used the bfloat16 aspect, and they decided that they didn't want to make the aspect a requirement of using bfloat16.

The bfloat16_type.cpp test compiles and runs for me using:

clang++ -fsycl -fsycl-targets=nvptx64-nvidia-cuda bfloat16_type.cpp -o res

You get the PI_ERROR_INVALID_BINARY if you try to run on cuda without passing the correct triple.

So I think you should allow bfloat16_type.cpp to run on cuda and delete bfloat16_type_cuda.cpp

For HIP that is an interesting question: I think that it also should support the bfloat16 class fully, but I dont have an AMD machine handy to check. I guess that it also failed previously due to not passing the triple. Is the HIP AMD CI is working atm?

[JackAKirk]

So there is an sm_80 in the CI now? Useful to know.

[steffenlarsen]

I don't think there is, but with the check we just skip if the device does not support it. I'd argue it is generally a bad practice to write the tests in a way that makes them dependent on what we have in CI, as anyone running it on other systems would see failures if we do. You could argue though that skipping without more information than a hidden message is also a bad practice, but in my opinion it is the lesser evil. 😄

[JackAKirk]

I see. Yeah make sense thanks!

[steffenlarsen]

Thanks for clarifying, @JackAKirk! In that case I don't see why we would need the builtin_type_cuda.cpp variant anymore, so I've changed it so that it just uses builtin_type.cpp. Additionally, I've changed it so it tries to run the SM80 build on CUDA but skips if the device doesn't support it.