[all-commits] [llvm/llvm-project] ed10fb: [ThinLTO] Allow importing based on a workload defi...

[Mircea Trofin via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: ed10fba1b274b81e1f119eab7a074a273df9ec32
      https://github.com/llvm/llvm-project/commit/ed10fba1b274b81e1f119eab7a074a273df9ec32
  Author: Mircea Trofin <mtrofin at google.com>
  Date:   2023-12-14 (Thu, 14 Dec 2023)

  Changed paths:
    M llvm/lib/Transforms/IPO/FunctionImport.cpp
    A llvm/test/ThinLTO/X86/workload.ll

  Log Message:
  -----------
  [ThinLTO] Allow importing based on a workload definition (#74545)

An example of a "workload definition" would be "the transitive closure of functions actually called to satisfy a RPC request", i.e. a (typically significantly) smaller subset of the transitive closure (static + possible indirect call targets) of callees. This means this workload definition is a type of flat dynamic profile.

Producing one is not in scope - it can be produced offline from traces, or from sample-based profiles, etc.

This patch adds awareness to ThinLTO of such a concept. A workload is defined as a root and a list of functions. All function references are by-name (more readable than GUIDs). In the case of aliases, the expectation is the list contains all the alternative names.

The workload definitions are presented to the linker as a json file, containing a dictionary. The keys are the roots, the values are the list of functions.

The import list for a module defining a root will be the functions listed for it in the profile.

Using names this way assumes unique names for internal functions, i.e. clang's `-funique-internal-linkage-names`.

Note that the behavior affects the entire module where a root is defined (i.e. different workloads best be defined in different modules), and does not affect modules that don't define roots.