[llvm-dev] Question about visibility analysis for whole program devirtualization pass

[Peter Collingbourne via llvm-dev]

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>