llvm-mirror/test/ThinLTO/X86/referenced_by_constant.ll
Teresa Johnson df6ad35dda [ThinLTO] Stop importing constant global vars as copies in the backend
Summary:
We were doing an optimization in the ThinLTO backends of importing
constant unnamed_addr globals unconditionally as a local copy (regardless
of whether the thin link decided to import them). This should be done in
the thin link instead, so that resulting exported references are marked
and promoted appropriately, but will need a summary enhancement to mark
these variables as constant unnamed_addr.

The function import logic during the thin link was trying to handle
this proactively, by conservatively marking all values referenced in
the initializer lists of exported global variables as also exported.
However, this only handled values referenced directly from the
initializer list of an exported global variable. If the value is itself
a constant unnamed_addr variable, we could end up exporting its
references as well. This caused multiple issues. The first is that the
transitively exported references weren't promoted. Secondly, some could
not be promoted/renamed (e.g. they had a section or other constraint).
recursively, instead of just adding the first level of initializer list
references to the ExportList directly.

Remove this optimization and the associated handling in the function
import backend. SPEC measurements indicate we weren't getting much
from it in any case.

Fixes PR31052.

Reviewers: mehdi_amini

Subscribers: krasin, llvm-commits

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

llvm-svn: 288446
2016-12-02 01:02:30 +00:00

33 lines
1.5 KiB
LLVM

; Do setup work for all below tests: generate bitcode and combined index
; RUN: opt -module-summary %s -o %t.bc
; RUN: opt -module-summary %p/Inputs/referenced_by_constant.ll -o %t2.bc
; RUN: llvm-lto -thinlto-action=thinlink -o %t3.bc %t.bc %t2.bc
; Check the import side: we currently only import bar() (with a future
; enhancement to identify constants in the summary, we should mark
; @someglobal/@someglobal2 for import as a local copy, which would
; cause @referencedbyglobal and @localreferencedbyglobal to be exported
; and promoted).
; RUN: llvm-lto -thinlto-action=import %t.bc -thinlto-index=%t3.bc -o - | llvm-dis -o - | FileCheck %s --check-prefix=IMPORT
; IMPORT: @someglobal.llvm.0 = external hidden unnamed_addr constant
; IMPORT: @someglobal2.llvm.0 = external hidden unnamed_addr constant
; IMPORT: define available_externally void @bar()
; Check the export side: we currently only export bar(), which causes
; @someglobal and @someglobal2 to be promoted (see above).
; RUN: llvm-lto -thinlto-action=promote %t2.bc -thinlto-index=%t3.bc -o - | llvm-dis -o - | FileCheck %s --check-prefix=EXPORT
; EXPORT: @someglobal.llvm.0 = hidden unnamed_addr constant
; EXPORT: @someglobal2.llvm.0 = hidden unnamed_addr constant
; EXPORT: define void @referencedbyglobal()
; EXPORT: define internal void @localreferencedbyglobal()
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.11.0"
declare void @bar()
define void @foo() {
call void @bar()
ret void
}