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

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

-I

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

-I

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>