[all-commits] [llvm/llvm-project] c27ab3: Restore "[ThinLTO] Avoid temporaries when loading ...

[Teresa Johnson via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: c27ab339ad8fcdd0abbe81ec9f44a440570de708
      https://github.com/llvm/llvm-project/commit/c27ab339ad8fcdd0abbe81ec9f44a440570de708
  Author: Teresa Johnson <tejohnson at google.com>
  Date:   2020-10-12 (Mon, 12 Oct 2020)

  Changed paths:
    M llvm/lib/Bitcode/Reader/MetadataLoader.cpp
    M llvm/test/ThinLTO/X86/Inputs/devirt2.ll
    M llvm/test/ThinLTO/X86/devirt2.ll

  Log Message:
  -----------
  Restore "[ThinLTO] Avoid temporaries when loading global decl attachment metadata"

This restores commit ab1b4810b55279bcf6fdd87be74a403440be3991 which was
reverted in 01b9deba76a950f04574b656c7c31ae389104f2d, with a fix for the
issue it caused. We should use a temporary BitstreamCursor when
loading the global decl attachment records so that the abbrev ids held
in the lazy loading IndexCursor are not clobbered. Enhanced the test so
that the issue is exposed there.

Original description:

When performing ThinLTO importing, the metadata loader attempts to lazy
load, by building an index. However, module level global decl attachment
metadata was being parsed early while building the index, since the
associated (module level) global values aren't materialized on demand.
This results in the creation of forward reference temporary metadatas,
which are expensive.

Normally, these module level global values don't have much attached
metadata. However, in the case of -fwhole-program-vtables (e.g. for
whole program devirtualization), the vtables may have many attached type
metadatas. This was resulting in very slow performance when performing
ThinLTO importing with the default lazy loading.

This patch restructures the handling of these global decl attachment
records, delaying their parsing until after the lazy loading index has
been built. Then the parser can use the interface that loads from the
index, which resolves forward references immediately instead of creating
expensive temporaries.

For one ThinLTO backend that imports from modules containing huge
numbers of vtables and associated types, I measured the following
compile times for the metadata materialization during function
importing, rounded to nearest second:

No -fwhole-program-vtables:
  Lazy loading on (head):  1s
  Lazy loading off (head): 3s
  Lazy loading on (patch): 1s

With -fwhole-program-vtables:
  Lazy loading on (head):  440s
  Lazy loading off (head): 4s
  Lazy loading on (patch): 2s

Differential Revision: https://reviews.llvm.org/D87970