[PATCH] D18328: [CUDA] Add option to mark most functions inside <complex> as host+device.

Artem Belevich via cfe-commits cfe-commits at lists.llvm.org
Mon Mar 21 14:56:30 PDT 2016

tra added a comment.

In http://reviews.llvm.org/D18328#379824, @rsmith wrote:

> I would much prefer for us to, say, provide a <complex> header that wraps the system one and does something like
>   // <complex>
>   #pragma clang cuda_implicit_host_device {
>   #include_next <complex>
>   #pragma clang cuda_implicit_host_device }
> or to provide an explicit list of the functions that we're promoting to `__host__` `__device__`, or to require people to use a CUDA-compatible standard library if they want CUDA-compatible standard library behaviour.

We'll still need some filtering as not everything inside <complex> should be `__host__` `__device__`.

Comment at: include/clang/Driver/Options.td:383-384
@@ -382,2 +382,4 @@
   HelpText<"Enable device-side debug info generation. Disables ptxas optimizations.">;
+def cuda_allow_std_complex : Flag<["--"], "cuda-allow-std-complex">,
+  HelpText<"Allow CUDA device code to use definitions from <complex>, other than operator>> and operator<<.">;
 def cuda_path_EQ : Joined<["--"], "cuda-path=">, Group<i_Group>,
rsmith wrote:
> I don't think it's reasonable to have something this hacky / arbitrary in the stable Clang driver interface.
What would be a better way to enable this 'feature'? I guess we could live with -Xclang -fcuda-allow-std-complex for now, but that does not seem to be particularly good way to give user control, either.

Perhaps we should have some sort of --cuda-enable-extension=foo option to control CUDA hacks.


More information about the cfe-commits mailing list