[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 08:51:47 PST 2021


tejohnson added a comment.

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

> @tejohnson I'm not sure this change is working correctly -- either that or my builds are messed up.
>
> `BitcodeCompiler::add` builds the resolutions for a bitcode module's symbols. For all symbols in the module `r.ExportDynamic` is set via `isExportDynamic`:
>
>   static bool isExportDynamic(Kind k, uint8_t visibility) {
>     if (k == SharedKind)
>       return visibility == llvm::ELF::STV_DEFAULT;
>     return config->shared || config->exportDynamic;
>   }
>
> The `Kind` for a `BitcodeFile` symbol is not `SharedKind` and thus `config->shared` causes this to always come back true. This is then used for `GlobalResolutions.ExportDynamic` which is used to build the `DynamicExportSymbols` list. Thus the `DynamicExportSymbols` list contains all the bitcode module's symbols and nothing gets `vcall_visibility`.

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.


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