[llvm-dev] RFC: Safe Whole Program Devirtualization Enablement
Teresa Johnson via llvm-dev
llvm-dev at lists.llvm.org
Tue Dec 17 08:32:55 PST 2019
On Tue, Dec 17, 2019 at 7:36 AM Iurii Gribov <Iurii.Gribov at ceva-dsp.com>
> (cc list this time)
> Hi Teresa,
> Apologies if this has been discussed before but ...
> > The LTO visibility of a class is derived at compile time from the
> class’s symbol visibility.
> > Generally, only classes that are internal at the source level (e.g.
> declared in an anonymous namespace) receive hidden LTO visibility.
> > Compiling with -fvisibility=hidden tells the compiler that, unless
> > otherwise marked, symbols are assumed to have hidden visibility, which
> > also implies that all classes have hidden LTO visibility (unless
> decorated with a public visibility attribute).
> > This results in much more aggressive devirtualization.
> Note that by default, unlike GCC, LLVM is liberal on
> visibility-constrained optimizations. In particular it freely performs
> inlining, IPA and cloning on them (see
> https://lists.llvm.org/pipermail/llvm-dev/2016-November/107625.html which
> also suggested adding -fsemantic-interposition to actually respect
> visibility in optimizations). It's unclear why devirtualization should
> behave differently than other optimizations (at least by default).
Are you suggesting that we should be more aggressive by default (i.e.
without -fvisibility=hidden or any new options)? I believe that will be too
aggressive for class LTO visibility. It is common to override a virtual
functions across shared library boundaries (e.g. a test may override a
virtual function from a shared library with a mock class). But with what I
am proposing we will assume it is safe under the proposed LTO link option,
which should be applied when linking statically other than e.g. system
Teresa Johnson | Software Engineer | tejohnson at google.com |
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev