rjmccall added a comment. In 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.) https://reviews.llvm.org/D53153 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
