hliao added a comment. In D80858#2170533 <https://reviews.llvm.org/D80858#2170533>, @yaxunl wrote:
> In D80858#2170328 <https://reviews.llvm.org/D80858#2170328>, @hliao wrote: > > > In D80858#2169534 <https://reviews.llvm.org/D80858#2169534>, @yaxunl wrote: > > > > > Another reason is that we need to support it in rdc mode, where different > > > TU can have static var with the same name. > > > > > > That's an issue of our current RDC support through LLVM IR instead of > > native code. The name conflicts are introduced as we link all TUs into a > > single module at IR level. The frontend should not be changed to support > > that. > > > I am not sure if ISA level linking would help for this. My understanding is > that the linker will rename the internal symbols having the same name from > different objects. It does not matter if it is llvm-link or native linker. > Once they are renamed we can no longer find them by name. > > I don't see a reason why we cannot support accessing static device variable > in FE. We have requests for this feature from different users. the register API also has a module ID parameter. With that, the runtime should be able to establish the map from the pointer of that host stub variable to its device module and the name within that module. For non-RDC case, that's already enough for the runtime to find the correct device variable. But, as `static` internal linkage is defined, it makes that identifier only visible to a single TU and not visible across TU. To be host, I think we still need to define that behaves in the context of CUDA or HIP as it obviously breaks the definition by making that `static` visible between host and device TUs in the restrict definition. 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
