tra added a comment. 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". 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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
