[PATCH] D80858: [CUDA][HIP] Support accessing static device variable in host code

Thu Jul 23 20:58:13 PDT 2020

hliao added a comment.

In D80858#2170821 <https://reviews.llvm.org/D80858#2170821>, @tra wrote:

> In D80858#2170781 <https://reviews.llvm.org/D80858#2170781>, @hliao wrote:
>
> > The problem is not whether we have solution to tell them but when we need to add that. Not all `static` device variables need to be visible to the host side. `Externalizing` them adds the overhead for the linker and may pose additional restrictions on aggressive optimizations. Do we have to support every ambiguous usage in the burden of the compiler change?
>
>
> It's a multi-part problem. 
>  The key request here is, IIUIC, to make TU-local variables visible within the TU on both host and the device. 
>  If and how it should be implemented is up for the discusstion. 
>  For me the request is reasonable and it would be good to have it as it would make the code behave according to general expectations of how TU-local variables behave -- "if it's in the same source file, it should be accessible from the functions in that file".

We may try to solve the issue without RDC firstly, where we don't need to change that static variable name (if the runtime maintains the device binaries correctly.) We only need to ensure the linker won't remove their symbols.

> I'm mostly discussing the 'how' part and we obviously don't have all the answers yet.
> 
> I agree, that adding the 'handles' for all non-visible variables is suboptimal and it may prove to be too big of a burden. That said, it does not look like an outright showstopper either. Ideally we only need those handles for the items that are being referred to by the host. Most likely most of them will not be. The problem is that it's the host-side compilation which knows which symbols will be needed, but it's the device-side compilation where we would have to generate aliases and, generally speaking, device-side compilation may not be able to ever tell which symbols will be needed by the host. I don't have a good solution for that. Ideally we need to have exact same AST on both sides and we can't guarantee that with the current implementation of HD functions and the use of preprocessor macros.
> 
>>> 
>>> 
>>>> 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.
>> 
>> Won't this patch just makes invisible variables "visible"?
> 
> Yes, but there will be no name conflicts, so for all practical purposes they don't change the end result of linking.

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

https://reviews.llvm.org/D80858