FP16 types are reported as unsupported for CUDA BE on compile time after cf6cc662

[vladimirlaz]

The problem was detected during LLVM pull down testing: http://ci.llvm.intel.com:8010/#/builders/37/builds/1152

It looks like a bug in diagnostics (AFAIK CUDA supports FP16) introduced by cf6cc66 and the tests passed before that patch.

[Fznamznon]

@vladimirlaz, could you please provide CUDA spec link where it says that FP16 is supported?

[Fznamznon]

I'm asking because nvptx target in clang doesn't define presence of float16 (FP16/half whatever) type whereas for exampler spir target does it

llvm/clang/lib/Basic/Targets/SPIR.h

Line 68 in f9226d2

HasFloat16 = true;

. That is why the diagnostic is triggered. I don't know why nvptx target doesn't define presence of FP16 type, maybe not all GPUs support this type.

[Naghasan]

@vladimirlaz, could you please provide CUDA spec link where it says that FP16 is supported?

The target support FP16 since sm_53 I believe. This is a clash with the declared Nvidia's OpenCL capabilities.

I'm aware of this, I have a patch to enable it locally but it is entangled with builtins fixes.

This reminds me, any particular reason you are using _Float16 and not __fp16 ?
With the proper definition of the frontend, __fp16 lowers to half if and only if the targets supports it (i16 otherwise), but _Float16 is automatically lowered to the half type regardless of the target. (maybe a question for @bader )

[vladimirlaz]

BTW: by default we are using sm_30. I tried to uplift it up to sm_75 (including sm_53 - I also find this in some post, i did not find spec), but it is still reported as unsupported.

here is the link: https://docs.nvidia.com/cuda/cufft/index.html#half-precision-transforms

[vladimirlaz]

@Naghasan, @Fznamznon I am going to proceed with pulldown and need workaround for the problem.

@Naghasan do you have any ETA for the fix?

• The easiest WA can be XFAIL LIT tests. But other staff like CTS are also affected and no WA there.
• The other option is to revert patch from @Fznamznon until the fix is ready. You will need to reapply patch with the fix.

I would apply option 2 if there are no objections and fix will ready reasonably fast (to avoid problems with ongoing LLVM pull downs).

[Naghasan]

@vladimirlaz Enable it if the triple has sycldevice, I'll refine it based on the capability.

[vladimirlaz]

I have prepared workaround (skip check for SYCL CUDA BE target tripple) 816febf
to unblock pulldown.

[vladimirlaz]

After applying comment the a4f4fa9 was submitted to sycl branch.

[pvchupin]

@Fznamznon @AlexeySachkov, @erichkeane can you comment on __fp16 vs _Float16 please?