[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