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

yaxunl marked 10 inline comments as done. yaxunl added inline comments. Comment at: clang/include/clang/Driver/Action.h:216 const llvm::opt::Arg &Input; - + unsigned Id; virtual void anchor(); rjmccall wrote: > Allowing an arbitrary string might be more ad

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

rjmccall added a comment. In addition to everyone else's concerns about generating this number randomly, it's also inherently less testable. I'm sure there's something else you could use that's reasonably likely to be unique, like a hash of the input filename or output filename or a combination

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

tra added a comment. In D80858#2067537 , @JonChesterfield wrote: > The value is based on llvm::sys::Process::GetRandomNumber(). So unless one > provides a build-system-derived uuid for every compilation unit, recompiling > identical source will yield an

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

JonChesterfield added a comment. The value is based on llvm::sys::Process::GetRandomNumber(). So unless one provides a build-system-derived uuid for every compilation unit, recompiling identical source will yield an observably different binary. The distinction between 'unique' and 'random' is s

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

yaxunl created this revision. yaxunl added reviewers: tra, rjmccall. nvcc supports accessing file-scope static device variables in host code by host APIs like cudaMemcpyToSymbol etc. HIP let users access device variables in host code by shadow variables. In host compilation, clang emits a shado