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

[Peter Collingbourne via llvm-dev]

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>