[PATCH] D91583: [LTO] Prevent devirtualization for symbols dynamically exported

Teresa Johnson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Mar 8 14:26:02 PST 2021


tejohnson added a comment.

In D91583#2612405 <https://reviews.llvm.org/D91583#2612405>, @lanza wrote:

>> To me this is WAI. Why is "config->shared" true for your bitcode module? This should only affect when using the linker flags that assert you have whole program visibility during the link, which isn't true for a shared library and its symbols.
>
> Got ya. For our Android apps we compute the actual `import` and `export` lists exactly and thus can compute the symbol visibility during linking and use `--lto-whole-program-visibility` accordingly. (Though this is not yet used in production for build system reasons). This change makes the list of symbols equivalent to the list of `DynamicExportSymbols`, so even though we can tell lld that `_ZTVN3xyz` is internal-only it won't get `vcall_visibility`.

I see - so just to confirm, when compiling it isn't clear that these symbols are have internal or hidden visibility, but only during linking? Because otherwise clang should already have applied an appropriate vcall_visibility that allows WPD.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D91583/new/

https://reviews.llvm.org/D91583



More information about the llvm-commits mailing list