Iurii Gribov via llvm-dev
2019-Dec-17 15:36 UTC
[llvm-dev] RFC: Safe Whole Program Devirtualization Enablement
(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). -I
Iurii Gribov via llvm-dev
2019-Dec-17 16:46 UTC
[llvm-dev] 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 boundariesI'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
Apparently Analagous Threads
- RFC: Safe Whole Program Devirtualization Enablement
- RFC: Safe Whole Program Devirtualization Enablement
- RFC: Safe Whole Program Devirtualization Enablement
- RFC: A new ABI for virtual calls, and a change to the virtual call representation in the IR
- RFC: Add an "interposible" linkage type (and implement -fsemantic-interposition)