Gainullin, Artur via llvm-dev
2017-Nov-30 09:56 UTC
[llvm-dev] Question about visibility analysis for whole program devirtualization pass
Hi! I have a question about whole program devirtualization pass. According to my understanding devirtualization is performed only for the classes that have hidden LTO visibility and this visibility is controlled by attributes in the source level or command line options. So visibility analysis is currently performed only in the front-end. But LLVM has LTO internalization pass that uses information from the linker to mark symbols as internal if it is possible. Have you ever considered to make an analysis of visibility at this level (after internalization pass)? Or it is not possible for some reasons? Best regards, Artur Gainullin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171130/81772fb3/attachment.html>
Gainullin, Artur via llvm-dev
2017-Dec-05 14:41 UTC
[llvm-dev] Question about visibility analysis for whole program devirtualization pass
Hi! Will appreciate any comments regarding this question. Best regards, Artur Gainullin From: Gainullin, Artur Sent: Thursday, November 30, 2017 10:56 AM To: peter at pcc.me.uk Cc: llvm-dev at lists.llvm.org Subject: Question about visibility analysis for whole program devirtualization pass Hi! I have a question about whole program devirtualization pass. According to my understanding devirtualization is performed only for the classes that have hidden LTO visibility and this visibility is controlled by attributes in the source level or command line options. So visibility analysis is currently performed only in the front-end. But LLVM has LTO internalization pass that uses information from the linker to mark symbols as internal if it is possible. Have you ever considered to make an analysis of visibility at this level (after internalization pass)? Or it is not possible for some reasons? Best regards, Artur Gainullin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171205/9aed7ad2/attachment.html>
Peter Collingbourne via llvm-dev
2017-Dec-06 03:36 UTC
[llvm-dev] Question about visibility analysis for whole program devirtualization pass
Hi Artur, Unfortunately, making a visibility analysis at that level would not always give correct results because the symbol information provided by the linker is insufficient to make determinations about which type hierarchies are closed at LTO time. For example, consider a main program with a plugin interface class defined like this: struct PluginInterface { virtual void f(); }; where plugins in external shared objects implement the plugin interface by deriving from PluginInterface. The problem is that deriving from PluginInterface in a shared object does not necessarily result in a reference to any of the symbols associated with PluginInterface, including its vtable. This would mean that even if plugin shared objects are linked into the main program at link time, LTO may be able to internalize all symbols relating to PluginInterface (and if plugins are dynamically loaded with dlopen(), the linker has absolutely no opportunity to see references to PluginInterface symbols). If we relied only on internalization information, this would cause the analysis to wrongly consider PluginInterface to be closed in the main program. Thanks, Peter On Thu, Nov 30, 2017 at 1:56 AM, Gainullin, Artur <artur.gainullin at intel.com> wrote:> Hi! > > > > I have a question about whole program devirtualization pass. According to > my understanding devirtualization is performed only for the classes that > have hidden LTO visibility and this visibility is controlled by attributes > in the source level or command line options. So visibility analysis is > currently performed only in the front-end. But LLVM has LTO > internalization pass that uses information from the linker to mark symbols > as internal if it is possible. Have you ever considered to make an analysis > of visibility at this level (after internalization pass)? Or it is not > possible for some reasons? > > > > Best regards, > > Artur Gainullin > > >-- -- Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171205/66848d4d/attachment.html>
Bozhenov, Nikolai via llvm-dev
2017-Dec-06 16:48 UTC
[llvm-dev] Question about visibility analysis for whole program devirtualization pass
Hi Peter, Thanks for the reply. I agree that the base class vtable may be not referenced by a derived class. However, the vtable of a derived class has to reference its parent type_info, and so having type_info internalized means that the class is final, doesn’t it? Thanks, Nikolai From: Peter Collingbourne [mailto:peter at pcc.me.uk] Sent: Wednesday, December 6, 2017 4:36 AM To: Gainullin, Artur <artur.gainullin at intel.com> Cc: llvm-dev at lists.llvm.org Subject: Re: Question about visibility analysis for whole program devirtualization pass Hi Artur, Unfortunately, making a visibility analysis at that level would not always give correct results because the symbol information provided by the linker is insufficient to make determinations about which type hierarchies are closed at LTO time. For example, consider a main program with a plugin interface class defined like this: struct PluginInterface { virtual void f(); }; where plugins in external shared objects implement the plugin interface by deriving from PluginInterface. The problem is that deriving from PluginInterface in a shared object does not necessarily result in a reference to any of the symbols associated with PluginInterface, including its vtable. This would mean that even if plugin shared objects are linked into the main program at link time, LTO may be able to internalize all symbols relating to PluginInterface (and if plugins are dynamically loaded with dlopen(), the linker has absolutely no opportunity to see references to PluginInterface symbols). If we relied only on internalization information, this would cause the analysis to wrongly consider PluginInterface to be closed in the main program. Thanks, Peter On Thu, Nov 30, 2017 at 1:56 AM, Gainullin, Artur <artur.gainullin at intel.com<mailto:artur.gainullin at intel.com>> wrote: Hi! I have a question about whole program devirtualization pass. According to my understanding devirtualization is performed only for the classes that have hidden LTO visibility and this visibility is controlled by attributes in the source level or command line options. So visibility analysis is currently performed only in the front-end. But LLVM has LTO internalization pass that uses information from the linker to mark symbols as internal if it is possible. Have you ever considered to make an analysis of visibility at this level (after internalization pass)? Or it is not possible for some reasons? Best regards, Artur Gainullin -- -- Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171206/f9cdc919/attachment.html>
Seemingly Similar Threads
- Question about visibility analysis for whole program devirtualization pass
- RFC: Safe Whole Program Devirtualization Enablement
- RFC: Safe Whole Program Devirtualization Enablement
- RFC: Safe Whole Program Devirtualization Enablement
- RFC: Safe Whole Program Devirtualization Enablement