maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/ThinLTO/X86/local_name_conflict.ll

41 lines
1.8 KiB
LLVM
Raw Normal View History

[ThinLTO] Import static functions from the same module as caller Summary: We can sometimes end up with multiple copies of a local function that have the same GUID in the index. This happens when there are local functions with the same name that are in different source files with the same name (but in different directories), and they were compiled in their own directory so had the same path at compile time. In this case make sure we import the copy in the caller's module. While it isn't a correctness problem (the renamed reference which is based on the module IR hash will be unique since the module must have had an externally visible function that was imported), importing the wrong copy will result in lost performance opportunity since it won't be referenced and inlined. Reviewers: mehdi_amini Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28440 llvm-svn: 291841
2017-01-13 06:04:45 +08:00
; Test handling when two files with the same source file name contain
; static functions with the same name (which will have the same GUID
; in the combined index.
[ThinLTO] Handle conflicting local names gracefully Summary: r285871 introduced an assert that was overly aggressive in the case of a same-named local in different same-named files (in different directories), where the source name and therefore the GUID ended up the same because the files were compiled in their own directory without any leading path. Change the handling in the promotion logic to get the summary for the version in that module. This also exposed an issue where we are not always importing the right copy, which is a performance not correctness issue (because the renaming is based on the module hash which must be different, see the bug report for details). I will fix that as a follow-on. Fixes PR31561. Reviewers: mehdi_amini Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28411 llvm-svn: 291304
2017-01-07 07:38:41 +08:00
; 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
[ThinLTO] Import static functions from the same module as caller Summary: We can sometimes end up with multiple copies of a local function that have the same GUID in the index. This happens when there are local functions with the same name that are in different source files with the same name (but in different directories), and they were compiled in their own directory so had the same path at compile time. In this case make sure we import the copy in the caller's module. While it isn't a correctness problem (the renamed reference which is based on the module IR hash will be unique since the module must have had an externally visible function that was imported), importing the wrong copy will result in lost performance opportunity since it won't be referenced and inlined. Reviewers: mehdi_amini Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28440 llvm-svn: 291841
2017-01-13 06:04:45 +08:00
; This module will import b() which should cause the copy of foo 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: call i32 @foo.llvm.[[HASH:[0-9A-F]+]]
; 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: define internal i32 @foo()
; Make sure foo is promoted and renamed without complaint in %t3.bc.
[ThinLTO] Handle conflicting local names gracefully Summary: r285871 introduced an assert that was overly aggressive in the case of a same-named local in different same-named files (in different directories), where the source name and therefore the GUID ended up the same because the files were compiled in their own directory without any leading path. Change the handling in the promotion logic to get the summary for the version in that module. This also exposed an issue where we are not always importing the right copy, which is a performance not correctness issue (because the renaming is based on the module hash which must be different, see the bug report for details). I will fix that as a follow-on. Fixes PR31561. Reviewers: mehdi_amini Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28411 llvm-svn: 291304
2017-01-07 07:38:41 +08:00
; RUN: llvm-lto -thinlto-action=promote %t3.bc -thinlto-index=%t4.bc -o - | llvm-dis -o - | FileCheck %s --check-prefix=EXPORTSTATIC
; 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(...)