llvm dev - Dec 2019 - RFC: Safe Whole Program Devirtualization Enablement

On Wed, Dec 18, 2019 at 3:38 AM Iurii Gribov via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> (Readding Hal)
>
> > 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
>
> I'm myself a fan of GCC's conservative approach so I'd agree
with you on
> that. But regardless of my personal opinions, LLVM already optimizes normal
> functions in shared libraries (thus mercilessly breaking overrides via
> LD_PRELOAD, etc.) and I don't see how virtual functions are any
different.
> I think default LLVM behavior needs to be consistent for all
> inter-procedural optimizations (be it inlining, devirtualization or
> cloning).
>
> Maybe it's time to resurrect Hal's -fsemantic-interposition flag
and use
> it consistently throughout compiler? Users who need GCC-like semantics will
> be able to employ this flag to prevent unsafe optimizations.
>
-fsemantic-interposition controls whether the compiler may assume that
symbols are not interposed, and it has nothing to do with the optimization
proposed here. The concern here is whether the user may derive from a class
defined in another shared object, and that does not involve symbol
interposition.

Peter

> -I
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191218/a5c2f507/attachment.html>

> -fsemantic-interposition controls whether the compiler may assume that
symbols are not interposed,
> and it has nothing to do with the optimization proposed here.
Thanks Peter, you are probably right. I've overestimated the information
that's available to LTO optimizer at link time.

Leaving shared libraries aside, one might argue that when LTOptimizing main
executable file compiler/linker is aware of all participating libraries and so
can decide whether class is not derived from and apply devirtualization based on
that information (assuming that run-time library implementations or dlopen calls
do not introduce new inherited classes at runtime, that's where
-fno-semantic-interposition assumption comes into play). But the "decide
whether class is not derived from" part here is problematic - derived
classes in libraries may have hidden visibility and will go undetected.

-I

On Thu, Dec 19, 2019 at 1:27 AM Iurii Gribov <Iurii.Gribov at
ceva-dsp.com>
wrote:
> > -fsemantic-interposition controls whether the compiler may assume that
> symbols are not interposed,
> > and it has nothing to do with the optimization proposed here.
>
> Thanks Peter, you are probably right. I've overestimated the
information
> that's available to LTO optimizer at link time.
>
> Leaving shared libraries aside, one might argue that when LTOptimizing
> main executable file compiler/linker is aware of all participating
> libraries and so can decide whether class is not derived from and apply
> devirtualization based on that information (assuming that run-time library
> implementations or dlopen calls do not introduce new inherited classes at
> runtime, that's where -fno-semantic-interposition assumption comes into
> play). But the "decide whether class is not derived from" part
here is
> problematic - derived classes in libraries may have hidden visibility and
> will go undetected.
>
Right, this is why we need some guarantee from the user that the LTO link
will see all derived classes. Currently at head the only way to do so is
via -fvisibility=hidden when compiling to bitcode. This proposal adds
another mechanism, pre-enabling the bitcode for WPD and delaying the
guarantee until LTO link time with an option there.

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/20191219/a22b7ca4/attachment.html>