[SYCL][CUDA] Define __SYCL_CUDA_ARCH__ instead of __CUDA_ARCH__ for SYCL

[GeorgeWeb]

This PR addresses an issue where if we use __CUDA_ARCH__ causes intrinsics not to be defined in the CUDA include files.

• Replace __CUDA_ARCH__ with __SYCL_CUDA_ARCH__ for SYCL device
• Update the sycl-macro.cpp test to check the appropriate macro.

---

As far as I could find the original issue was introduced from PR #6524 for enabling the bfloat16 support moving it from the experimental extension, and it breaks some codebases with CUDA interop calls.
Current reports include github issues #7722, #8133 and oneapi-src/oneMKL#257.

For that reason we define a unique __SYCL_CUDA_ARCH__ macro and use it instead for SYCL device targets and leave __CUDA_ARCH__ as before for CUDA targets.

[hdelan]

Otherwise LGTM!

[zjin-lcf]

I have a question. Is __SYCL_HIP_ARCH__ needed ?

[elizabethandrews]

FE changes LGTM

[hdelan]

Hi @zjin-lcf we don't want to add too many of these arch checkers in DPC++ if we can help it since they are a little hacky. We need SYCL_CUDA_ARCH because some of the headers use it and it reduces the amount of code we compile. Nevertheless we can get this kind of functionality with AMD HIP backend by declaring an extern int that will be resolved at llvm-link time:

https://github.com/intel/llvm/blob/sycl/libclc/amdgcn-amdhsa/libspirv/atomic/atomic_add.cl#L13

We can then check the arch value like this:

https://github.com/intel/llvm/blob/sycl/libclc/amdgcn-amdhsa/libspirv/atomic/atomic_helpers.h#L14

[abagusetty]

@GeorgeWeb Thanks for the PR. I can verify, this was addressed uxlfoundation/oneMath#257

[smanna12]

FE changes look OK to me

[premanandrao]

FE changes look okay to me.

[abagusetty]

Hi @bso-intel , @intel/llvm-gatekeepers Can we get some help with this PR. It would unblock several issues mentioned above. Thanks

[bader]

@abagusetty, code review from code owners is missing. Please, ping @intel/llvm-reviewers-runtime team.

[abagusetty]

@intel/llvm-reviewers-runtime Could you please help with the review

[steffenlarsen]

Looks like a reasonable solution! Thanks!