[PATCH] D54815: [ThinLTO] Add summary entries for index-based WPD

Teresa Johnson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 11 18:11:14 PST 2019


tejohnson added a comment.

In D54815#1354850 <https://reviews.llvm.org/D54815#1354850>, @davidxl wrote:

> Vtable funcs info should be in the initializers of vtable global variables right?


The IRSymtab doesn't hold the initializers of global variable symbols. It only holds the information necessary for LTO to provide information to the linkers to drive linker based symbol resolution.

As we discussed offline, one could imagine moving this information in the IRSymtab (it is currently in the IR MODULE_BLOCK), and then sharing with the summary, but this is a much bigger restructuring that would need to be considered separately.  E.g. in the MODULE_BLOCK the global var prototype is in a different record than its definition initializer, and other than the string table there isn't any sharing between the info in the MODULE_BLOCK and the IRSymtab AFAIK. Before moving the initializer into the IRSymtab it would make sense to start by deduplicating other symbol information between the MODULE_BLOCK and the IRSymtab (I recall discussing this with @pcc at some point but don't recall what conclusion we came to). And then this would also require integration between the summary block and the IRSymtab which, again other than the string table, are separate entities without shared information or cross references.

One thing to note about this patch is that we already hold in the GLOBALVAR summary entry all the references to other symbols in its initializer (which are maintained as an array of essentially pointers to other summary index entries), however with the new FS_PERMODULE_VTABLE_GLOBALVAR_INIT_REFS record, and as well in the in memory summary representation, we end up essentially duplicating those references for vtable defs. I could presumably come up with a way of consolidating those. I had convinced myself that there weren't enough vtable defs to warrant too much restructuring, but let me see if I can come up with a clean way to do this that doesn't bloat non-vtable globalvar summaries.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54815/new/

https://reviews.llvm.org/D54815





More information about the llvm-commits mailing list