[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.
http://reviews.llvm.org/D18328
More information about the cfe-commits
mailing list