[PATCH] D43361: [ThinLTO] Enable AutoHide on symbols with local_unnamed_addr

[Peter Collingbourne via Phabricator via llvm-commits]

pcc added a comment.

In https://reviews.llvm.org/D43361#1010401, @steven_wu wrote:

> In https://reviews.llvm.org/D43361#1009616, @pcc wrote:
>
> > > There is an alternative which is to teach linker to deduct auto hide property from the bitcode file and overwrite the linkage type afterwards. For C API, there is a new scope LTO_SYMBOL_SCOPE_DEFAULT_CAN_BE_HIDDEN can be used to do that but that will be forced the work onto all the linker which is probably not desirable but it solves the same problem.
> >
> > This seems better to me. Ideally the linker should be reading and resolving symbols from bitcode files in the same way as regular object files, including the auto-hide bit. Linkers would need something similar for any other properties that are contained only in bitcode files but not in object files (such as a general address-taken bit).
>
>
> But this is extremely fragile, especially through C API. Linker can never trust 100% of all the information provided in the bitcode because there can be optimizations in the LTO pipeline that modify/add/delete any symbols or attributes. Unless the linker knows about all the optimizations, it is risky for linker to redo the linkage change from the optimizers and expect that there are no side affects. In this case, for example, if someone implement an optimization that can introduce code that taken the address of local_unnamed_addr and remove the attributes, then linker is not allowed to auto hide, even through all the original bitcode says unnamed_addr.


The unnamed_addr attribute means that the address is semantically significant. If a pass changes whether a global's address is semantically significant, that is a change in semantics and a bug in the pass.


Repository:
  rL LLVM

https://reviews.llvm.org/D43361