scott.linder added a comment. 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. 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
