yaxunl added a comment.

In D62603#1521832 <https://reviews.llvm.org/D62603#1521832>, @tra wrote:

> In D62603#1521792 <https://reviews.llvm.org/D62603#1521792>, @hliao wrote:
>
> > that should assume that variable is not declared with `static`. that's also 
> > the motivation of this patch.
>
>
> cppreference defines internal linkage as 'The name can be referred to from 
> all scopes in the current translation unit.'
>  The current translation unit in CUDA context gets a bit murky. On one hand 
> host and device are compiled separately, and may conceivably be considered 
> separate TUs. On the other hand, the fact that we mix host and device code in 
> the same source file implies tight coupling and the users do expect them to 
> be treated as if all host and device code in the source file is in the same 
> TU. E.g. you may have a kernel in an anonymous namespace yet you do want to 
> be able to launch it from the host side.
>
> I think `static __device__` globals would fall into the same category -- 
> nominally they should not be visible outside of device-side object file, but 
> in practice we do need to make them visible from the host side of the same TU.


Are you sure nvcc support accessing static `__device__` variables in host code? 
That would be expensive to implement. Instead of looking up dynamic symble 
tables only, now we need to look up symbol tables for local symbols. Also we 
have to differentiate local symbols that have the same name. This also means 
user can not strip symbol tables.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62603/new/

https://reviews.llvm.org/D62603



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to