[llvm-dev] RFC: Safe Whole Program Devirtualization Enablement

[Teresa Johnson via llvm-dev]

On Tue, Dec 17, 2019 at 7:36 AM Iurii Gribov <Iurii.Gribov at ceva-dsp.com>
wrote:

> (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
libraries.

Thanks,
Teresa


> -I
>
>

-- 
Teresa Johnson |  Software Engineer |  tejohnson at google.com |
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191217/ca109dfe/attachment.html>