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

Peter Collingbourne via llvm-dev llvm-dev at lists.llvm.org
Wed Dec 18 13:09:49 PST 2019

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


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

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

More information about the llvm-dev mailing list