scott.linder added a subscriber: b-sumner. scott.linder added a comment. 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. https://reviews.llvm.org/D53153 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
