mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-10-20 03:23:01 +02:00
525ee88977
Summary: We can sometimes end up with multiple copies of a local variable that have the same GUID in the index. This happens when there are local variables with the same name that are in different source files having the same name/path at compile time (but compiled into different bitcode objects). In this case make sure we import the copy in the caller's module. This enables importing both of the variables having the same GUID (but which will have different promoted names since the module paths, and therefore the module hashes, will be distinct). Importing the wrong copy is particularly problematic for read only variables, since we must import them as a local copy whenever referenced. Otherwise we get undefs at link time. Note that the llvm-lto.cpp and ThinLTOCodeGenerator changes are needed for testing the distributed index case via clang, which will be sent as a separate clang-side patch shortly. We were previously not doing the dead code/read only computation before computing imports when testing distributed index generation (like it was for testing importing and other ThinLTO mechanisms alone). Reviewers: evgeny777 Subscribers: mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, dang, llvm-commits Differential Revision: https://reviews.llvm.org/D55047 llvm-svn: 347886
44 lines
2.0 KiB
LLVM
44 lines
2.0 KiB
LLVM
; Test handling when two files with the same source file name contain
|
|
; static functions/variables with the same name (which will have the same GUID
|
|
; in the combined index.
|
|
|
|
; Do setup work for all below tests: generate bitcode and combined index
|
|
; RUN: opt -module-summary -module-hash %s -o %t.bc
|
|
; RUN: opt -module-summary -module-hash %p/Inputs/local_name_conflict1.ll -o %t2.bc
|
|
; RUN: opt -module-summary -module-hash %p/Inputs/local_name_conflict2.ll -o %t3.bc
|
|
; RUN: llvm-lto -thinlto-action=thinlink -o %t4.bc %t.bc %t2.bc %t3.bc
|
|
|
|
; This module will import b() which should cause the copy of foo and baz from
|
|
; that module (%t3.bc) to be imported. Check that the imported reference's
|
|
; promoted name matches the imported copy.
|
|
; RUN: llvm-lto -thinlto-action=import %t.bc -thinlto-index=%t4.bc -o - | llvm-dis -o - | FileCheck %s --check-prefix=IMPORT
|
|
; IMPORT: @baz.llvm.[[HASH:[0-9]+]] = available_externally hidden constant i32 10, align 4
|
|
; IMPORT: call i32 @foo.llvm.[[HASH]]
|
|
; IMPORT: define available_externally hidden i32 @foo.llvm.[[HASH]]()
|
|
|
|
; The copy in %t2.bc should not be exported/promoted/renamed
|
|
; RUN: llvm-lto -thinlto-action=promote %t2.bc -thinlto-index=%t4.bc -o - | llvm-dis -o - | FileCheck %s --check-prefix=NOEXPORTSTATIC
|
|
; NOEXPORTSTATIC: @baz = internal constant i32 10, align 4
|
|
; NOEXPORTSTATIC: define internal i32 @foo()
|
|
|
|
; Make sure foo is promoted and renamed without complaint in %t3.bc.
|
|
; RUN: llvm-lto -thinlto-action=promote %t3.bc -thinlto-index=%t4.bc -o - | llvm-dis -o - | FileCheck %s --check-prefix=EXPORTSTATIC
|
|
; EXPORTSTATIC: @baz.llvm.{{.*}} = hidden constant i32 10, align 4
|
|
; EXPORTSTATIC: define hidden i32 @foo.llvm.
|
|
|
|
; ModuleID = 'local_name_conflict_main.o'
|
|
source_filename = "local_name_conflict_main.c"
|
|
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
|
|
target triple = "x86_64-unknown-linux-gnu"
|
|
|
|
; Function Attrs: noinline nounwind uwtable
|
|
define i32 @main() {
|
|
entry:
|
|
%retval = alloca i32, align 4
|
|
store i32 0, i32* %retval, align 4
|
|
%call = call i32 (...) @b()
|
|
ret i32 %call
|
|
}
|
|
|
|
declare i32 @b(...)
|