llvm dev - Dec 2017 - 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>

There are two problems with that. Firstly, this will only work on classes
compiled with RTTI. Secondly, this analysis would produce a false negative
if the base class is compiled with RTTI and the derived class is compiled
without RTTI.

Peter

On Dec 6, 2017 08:48, "Bozhenov, Nikolai" <nikolai.bozhenov at
intel.com>
wrote:

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>
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/e2f54893/attachment.html>

Peter,

Thanks for pointing to RTTI. Unfortunately, you are right. When mixing RTTI and
non-RTTI objects, visibility of type_info gets meaningless for detecting final
classes. And I presume there is no way to check at link-time if there are any
objects without RTTI…

Looks like hidden symbol visibility is indeed the only way to get proper
devirtualization.

Thanks,
Nikolai


From: Peter Collingbourne [mailto:peter at pcc.me.uk]
Sent: Wednesday, December 6, 2017 8:05 PM
To: Bozhenov, Nikolai <nikolai.bozhenov at intel.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>; Gainullin, Artur
<artur.gainullin at intel.com>; Elovikov, Andrei <andrei.elovikov at
intel.com>
Subject: RE: Question about visibility analysis for whole program
devirtualization pass

There are two problems with that. Firstly, this will only work on classes
compiled with RTTI. Secondly, this analysis would produce a false negative if
the base class is compiled with RTTI and the derived class is compiled without
RTTI.

Peter

On Dec 6, 2017 08:48, "Bozhenov, Nikolai" <nikolai.bozhenov at
intel.com<mailto:nikolai.bozhenov at intel.com>> wrote:
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<mailto:peter at
pcc.me.uk>]
Sent: Wednesday, December 6, 2017 4:36 AM
To: Gainullin, Artur <artur.gainullin at intel.com<mailto:artur.gainullin
at intel.com>>
Cc: llvm-dev at lists.llvm.org<mailto: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/20171207/aeee33ef/attachment-0001.html>