rjmccall added a comment. In D53153#1314777 <https://reviews.llvm.org/D53153#1314777>, @scott.linder wrote:
> In D53153#1291348 <https://reviews.llvm.org/D53153#1291348>, @rjmccall wrote: > > > In D53153#1289380 <https://reviews.llvm.org/D53153#1289380>, @scott.linder > > wrote: > > > > > I don't believe that is currently the case (the unrestricted linking of > > > OCL code to OCL code via a dynamic linker), but we do have the notion of > > > a static link step, followed by dynamic linking at runtime. The static > > > link step is currently via IR, but we plan to support linking object > > > files. Maybe I misunderstand the distinction between linkage and > > > visibility, but it seems reasonable that a user would want to have e.g. a > > > non-kernel function participate in static linking, but not be preemptible > > > in the final shared object. The intention with this patch is to allow > > > this with something like `-fvisibility hidden` without disrupting kernel > > > symbols, which must appear in the dynsym for the reasons mentioned > > > earlier in the thread. > > > > > > Okay, this still doesn't need user-controlled symbol visibility. The basic > > question here is whether there is any need for anything other than kernel > > functions to have dynamic linkage. If not, then you really just need to > > mark everything as hidden except for kernels. You *could* do that marking > > in Sema, but frankly that seems like an implementation detail escaping into > > the AST, and it's just going to cause you unwanted pain and sub-optimality. > > (For example: `-fvisibility=hidden` doesn't actually change the visibility > > of external declarations for reasons that make a lot of sense for > > general-purpose environments but probably don't matter to you at all. If > > you're doing this to get better code-generation for references to external > > entities that are going to end up within the image, you actually need to > > add a visibility attribute to every single top-level declaration to get > > that effect. It's much easier to just do it in a pass on the module.) > > > If such a pass were to mark all non-kernel symbols as hidden, for example, > how would it support languages other than OpenCL where the runtime > constraints differ? AMDGPU supports other languages where the assumption that > only kernel functions must be visible is not valid. Can a module pass > override visibility without making assumptions about the source language? I > may just be unfamiliar with Clang, and not know where this sort of pass would > live. > > I think a pass which only overrides kernel function visibility (i.e. by > forcing it to be default) would always be correct, but touching other symbol > visibility begins to make assumptions which are not necessarily valid for all > languages. You still have the same linkage model for those other languages, right? Ultimately there's something like a kernel function that has to be declared specially and which becomes the only public interface of the code? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D53153/new/ https://reviews.llvm.org/D53153 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
