rjmccall added a comment. In D53153#1315107 <https://reviews.llvm.org/D53153#1315107>, @yaxunl wrote:
> In D53153#1315039 <https://reviews.llvm.org/D53153#1315039>, @scott.linder > wrote: > > > In D53153#1314798 <https://reviews.llvm.org/D53153#1314798>, @rjmccall > > wrote: > > > > > You still have the same linkage model for those other languages, right? > > > Ultimately there's something like a kernel function that has to be > > > declared specially and which becomes the only public interface of the > > > code? > > > > > > I don't think this is true for all languages targeting AMDGPU. For example, > > HIP has APIs like `hipMemcpyToSymbol` which accept a string identifying a > > symbol for a variable in global/constant address space. @yaxunl is my > > understanding about the HIP runtime requiring dynamic symbols for global > > variables correct here? > > > Right. There is also hipGetSymbolAddress which returns address of a global > variable in device memory given the name of the variable. Therefore we cannot > hide the global variables. Okay. So it's still the case that all symbols will be defined within the linkage unit; it's just that some things might need to get exposed outside of it. LLVM does provide a `dso_local` attribute which you could use unconditionally on every symbol without actually changing visibility. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D53153/new/ https://reviews.llvm.org/D53153 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
