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

[Reid Kleckner via cfe-commits]

rnk 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.


I don't really like include_next wrapper headers, but adding a pragma spelling of the cuda device attributes might be nice. There would still be issues with the streaming operators, though.


================
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>,
----------------
jlebar wrote:
> tra wrote:
> > 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.
> > I don't think it's reasonable to have something this hacky / arbitrary in the stable Clang driver interface.
> 
> This is an important feature for a lot of projects, including tensorflow and eigen.  No matter how we define the flag, I suspect people are going to use it en masse.  (Most projects I've seen pass the equivalent flag to nvcc.)  At the point that many or even most projects are relying on it, I'd suspect we'll have difficulty changing this flag, regardless of whether or not it is officially part of our stable API.
> 
> There's also the issue of discoverability.  nvcc actually gives a nice error message when you try to use std::complex -- it seems pretty unfriendly not to even list the relevant flag in clang --help.
> 
> I don't feel particularly strongly about this, though -- I'm more concerned about getting something that works.
What if we had a catchall nvcc quirks mode flag similar to -fms-compatibility? We probably don't want a super fine grained LangOpt like this.


http://reviews.llvm.org/D18328