scott.linder added a comment. In https://reviews.llvm.org/D53153#1263835, @yaxunl wrote:
> In https://reviews.llvm.org/D53153#1263810, @scott.linder wrote: > > > In https://reviews.llvm.org/D53153#1263804, @rsmith wrote: > > > > > In https://reviews.llvm.org/D53153#1263771, @scott.linder wrote: > > > > > > > The rationale is that `-fvisibility` only affects the default, and > > > > already does not apply in many cases. For example, see the rest of the > > > > conditions above the fvisibility check in `getLVForNamespaceScopeDecl`: > > > > when `Var->getStorageClass() == SC_Static` the linkage is (usually) > > > > internal and the visibility is default. > > > > > > > > > Visibility is meaningless for an internal-linkage declaration. > > > > > > > I think one question is whether OpenCL language semantics allow us to > > > > make these visibility determinations; I am going off of the APIs > > > > available to access symbols. > > > > > > `-fvisibility` is not governed by the OpenCL specification; it's a Clang > > > / GCC extension, and we get to determine its semantics, which generally > > > override the rules from the language model we're implementing. > > > > > > I'm a little surprised that symbol visibility is even meaningful when > > > compiling GPU code. Can you give some more background on that? > > > > > > To the extent that visibility is meaningful, it does seem to make sense > > > for `kernel` to imply default visibility in the same way an attribute > > > would, since it's an unambiguous marker that the function is intended to > > > be called from outside the DSO. It's less obvious to me that the same is > > > true for global variables; is there no distinction in OpenCL between > > > global variables that can be accessed by the host and global variables > > > that are internal to the device-side computation? > > > > > > This makes more sense, thank you for the explanation. Ignore my last post, > > it makes sense that visibility is defaulted and ignored when a symbol is > > assigned internal linkage. > > > > I am still not confident about globals; maybe @b-sumner has more insight? > > We have APIs for accessing global variable symbols form the host, but this > > may be AMD-specific, not general to OpenCL. > > > One thing I can think of the global variables is their initialization. If > their initialization must be done by the runtime, then they have to be > visible to the runtime. Tony mentioned that in one of the CL2.X standards there is support for dynamic initialization of global variables, but I don't have a standard reference for that. https://reviews.llvm.org/D53153 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
