tra added a comment.

In D80858#2170604 <https://reviews.llvm.org/D80858#2170604>, @hliao wrote:
> In D80858#2170547 <https://reviews.llvm.org/D80858#2170547>, @tra wrote:
>
> > Would it work if we generate a globally unique visible aliases for the 
> > static vars and use the alias' name to register device-side entities 
> > without changing their visibility?
>
>
> We still need to define how a `static` device variable should be visible on 
> the host side.


As far as the host is concerned, if a 'static' variable is within the same TU 
it (or, rather, its shadow) should be accessible.

> How that behaves in the context of relocatable code generation as well as 
> anonymous namespaces.

AFAICT it would just work -- each TU only sees static things within that TU on 
both host and device sides. Visible module-unique aliases would allow host-side 
binary to get address of  an otherwise non-visible variables. I expect that 
will work with RDC -- because we didn't change the visibility of the symbols 
themselves, they behave according to the regular linking rules. The aliases are 
also globally unique, so they should present no issues either.

> Also, in the context of CUDA runtime/driver API, if a device variable is 
> addressable on the host side through the runtime API, it should be 
> addressable through the driver API as well. However, the naming will be a big 
> challenge.

I'm not convinced that I completely agree with this assertion. It's reasonable 
for visible symbols (though even then there's a question of how do you figure 
out a properly mangled name for that symbol), but expecting it to work for 
non-visible symbols would push it too far, IMO.
It will also have issues with RDC as the name resulution will become ambiguous. 
Compiler does have necessary info to resolve that ambiguity, runtime support 
library, too, but the driver does not. We'd have to provide the driver with the 
additional info to let it map host-side symbol info to its device counterpart. 
It's doable, but I don't think it's particularly useful in practice. If 
something needs to be accessed via the driver API, it would be reasonable to 
expect it to be a public symbol.


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

https://reviews.llvm.org/D80858



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

Reply via email to