[all-commits] [llvm/llvm-project] 7dc4bb: [ThinLTO] Handle variable with twice promoted name...

[Teresa Johnson via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 7dc4bbf8ab311606388faacca58b6c3e3e508b77
      https://github.com/llvm/llvm-project/commit/7dc4bbf8ab311606388faacca58b6c3e3e508b77
  Author: Teresa Johnson <tejohnson at google.com>
  Date:   2020-01-14 (Tue, 14 Jan 2020)

  Changed paths:
    M llvm/include/llvm/IR/ModuleSummaryIndex.h
    A llvm/test/ThinLTO/X86/Inputs/thinlto-internalize-doublepromoted.ll
    A llvm/test/ThinLTO/X86/thinlto-internalize-doublepromoted.ll

  Log Message:
  -----------
  [ThinLTO] Handle variable with twice promoted name (Rust)

Summary:
Ensure that we can internalize values produced from two rounds of
promotion.

Note that this cannot happen currently via clang, but in other use cases
such as the Rust compiler which does a first round of ThinLTO on library
code, producing bitcode, and a second round on the final binary.

In particular this can happen if a function is exported and promoted,
ending up with a ".llvm.${hash}" suffix, and then goes through a round
of optimization creating an internal switch table expansion variable
that is internal and contains the promoted name of the enclosing
function. This variable will be promoted in the second round of ThinLTO
if @foo is imported again, and therefore ends up with two
".llvm.${hash}" suffixes. Only the final one should be stripped when
consulting the index to locate the summary.

Reviewers: wmi

Subscribers: mehdi_amini, inglorion, hiraditya, JDevlieghere, steven_wu, dexonsmith, arphaman, llvm-commits

Tags: #llvm

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