[PATCH] D53153: [OpenCL] Mark namespace scope variables and kernel functions with default visibility

[Scott Linder via Phabricator via cfe-commits]

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