compnerd wrote:
> > It is possible to apply the hidden visibility to member functions on
> > classes. However, it does tend to complicate your ability to reason about
> > the code IMO (although the same argument holds for `__declspec(dllexport)`
> > on member functions. The attribute simply would prevent the member function
> > from participating in dynamic linking - so any other module would need to
> > define their own copy.
>
> That DOES sound error prone. I wonder if there is use to have this diagnose
> via a warning that explains this, particularly now that we are allowing this
> to be more easily added to members.
The interesting thing is the inverse case - which is what we are working
towards with the efforts to build LLVM as a DLL. We annotate the members
explicitly for their participation in the ABI via `LLVM_ABI`. The intention is
that all members will have `__attribute__((__visibility__("hidden")))` by
default via `-fvisibility-default=hidden` and then explicit members participate
in dynamic linkage by means of the `LLVM_ABI` attribute which expands to
`__attribute__((__visibility__("default")))` on ELFish (and MachO) targets.
On Linux, there is the possibility of further optimization by means of having
`LLVM_ABI` expand to `__attribute__((__visibility__("protected")))` which
permits the symbol to participate in global dynamic linkage, but prevents
interpositioning, allowing more efficient code generation (and avoids the need
for the use of the GOT within the defining module).
https://github.com/llvm/llvm-project/pull/145653
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
