maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lld/test/ELF/lto/common2.ll

29 lines
775 B
LLVM
Raw Normal View History

[LLD] Mark a number of x86 only tests to require x86 Noticed while testing for an out of tree target. There are probably more tests that should be so marked. I'm not sure who owns these tests so I've added a few names I recognise from the recent history. With advice from probinson, ruiu, rafael and dramatically improved by davidb. Thank you all! Differential Revision: https://reviews.llvm.org/D34685 llvm-svn: 308335
2017-07-19 02:40:50 +08:00
; REQUIRES: x86
[LTO] An interesting case which shows up how we handle common symbols. The gold plugin logic for common symbols is a little bit convoluted as the plugin API has not an explicit way to update the alignment. In gold, then, we need to keep the bitcode symbol @a around because that's the only way to get the alignment right in the final object. In lld, this is not true. We already have all the informations we need about common symbols (size/alignment) so we don't have to keep the existing symbol and pass it to the mover. llvm-svn: 267007
2016-04-22 01:11:39 +08:00
; RUN: llvm-as %s -o %t1.o
[ELF] Remove -m argument to lld in test files. NFC. This should be correctly implied by the linker. This also makes the tests slightly easier to maintain and compare with the equivalent tests under for other platforms. Differential Revision: https://reviews.llvm.org/D47513 llvm-svn: 333567
2018-05-31 01:57:08 +08:00
; RUN: ld.lld %t1.o -o %t -shared -save-temps
[ELF/LTO] Switch to the new resolution-based API. Differential Revision: https://reviews.llvm.org/D24492 llvm-svn: 282656
2016-09-29 08:40:08 +08:00
; RUN: llvm-dis < %t.0.2.internalize.bc | FileCheck %s
[LTO] An interesting case which shows up how we handle common symbols. The gold plugin logic for common symbols is a little bit convoluted as the plugin API has not an explicit way to update the alignment. In gold, then, we need to keep the bitcode symbol @a around because that's the only way to get the alignment right in the final object. In lld, this is not true. We already have all the informations we need about common symbols (size/alignment) so we don't have to keep the existing symbol and pass it to the mover. llvm-svn: 267007
2016-04-22 01:11:39 +08:00
; RUN: llvm-readobj -t %t | FileCheck %s --check-prefix=SHARED
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
@a = common global i8 0, align 8
Internalize common variables. Before this lld was always creating common symbols itself. It worked, but prevented them from being internalized when possible. Now it preserves common symbols is the bitcode and they are internalized. Fixes pr30184. llvm-svn: 280242
2016-08-31 21:42:08 +08:00
; CHECK-DAG: @a = common global i8 0, align 8
[LTO] An interesting case which shows up how we handle common symbols. The gold plugin logic for common symbols is a little bit convoluted as the plugin API has not an explicit way to update the alignment. In gold, then, we need to keep the bitcode symbol @a around because that's the only way to get the alignment right in the final object. In lld, this is not true. We already have all the informations we need about common symbols (size/alignment) so we don't have to keep the existing symbol and pass it to the mover. llvm-svn: 267007
2016-04-22 01:11:39 +08:00
Internalize common variables. Before this lld was always creating common symbols itself. It worked, but prevented them from being internalized when possible. Now it preserves common symbols is the bitcode and they are internalized. Fixes pr30184. llvm-svn: 280242
2016-08-31 21:42:08 +08:00
@b = common hidden global i32 0, align 4
define i32 @f() {
%t = load i32, i32* @b, align 4
ret i32 %t
}
; CHECK-DAG: @b = internal global i32 0, align 4
[LTO] An interesting case which shows up how we handle common symbols. The gold plugin logic for common symbols is a little bit convoluted as the plugin API has not an explicit way to update the alignment. In gold, then, we need to keep the bitcode symbol @a around because that's the only way to get the alignment right in the final object. In lld, this is not true. We already have all the informations we need about common symbols (size/alignment) so we don't have to keep the existing symbol and pass it to the mover. llvm-svn: 267007
2016-04-22 01:11:39 +08:00
; SHARED: Symbol {
; SHARED: Name: a
Internalize common variables. Before this lld was always creating common symbols itself. It worked, but prevented them from being internalized when possible. Now it preserves common symbols is the bitcode and they are internalized. Fixes pr30184. llvm-svn: 280242
2016-08-31 21:42:08 +08:00
; SHARED-NEXT: Value:
[LTO] An interesting case which shows up how we handle common symbols. The gold plugin logic for common symbols is a little bit convoluted as the plugin API has not an explicit way to update the alignment. In gold, then, we need to keep the bitcode symbol @a around because that's the only way to get the alignment right in the final object. In lld, this is not true. We already have all the informations we need about common symbols (size/alignment) so we don't have to keep the existing symbol and pass it to the mover. llvm-svn: 267007
2016-04-22 01:11:39 +08:00
; SHARED-NEXT: Size: 1
; SHARED-NEXT: Binding: Global
ELF: New symbol table design. This patch implements a new design for the symbol table that stores SymbolBodies within a memory region of the Symbol object. Symbols are mutated by constructing SymbolBodies in place over existing SymbolBodies, rather than by mutating pointers. As mentioned in the initial proposal [1], this memory layout helps reduce the cache miss rate by improving memory locality. Performance numbers: old(s) new(s) Without debug info: chrome 7.178 6.432 (-11.5%) LLVMgold.so 0.505 0.502 (-0.5%) clang 0.954 0.827 (-15.4%) llvm-as 0.052 0.045 (-15.5%) With debug info: scylla 5.695 5.613 (-1.5%) clang 14.396 14.143 (-1.8%) Performance counter results show that the fewer required indirections is indeed the cause of the improved performance. For example, when linking chrome, stalled cycles decreases from 14,556,444,002 to 12,959,238,310, and instructions per cycle increases from 0.78 to 0.83. We are also executing many fewer instructions (15,516,401,933 down to 15,002,434,310), probably because we spend less time allocating SymbolBodies. The new mechanism by which symbols are added to the symbol table is by calling add* functions on the SymbolTable. In this patch, I handle local symbols by storing them inside "unparented" SymbolBodies. This is suboptimal, but if we do want to try to avoid allocating these SymbolBodies, we can probably do that separately. I also removed a few members from the SymbolBody class that were only being used to pass information from the input file to the symbol table. This patch implements the new design for the ELF linker only. I intend to prepare a similar patch for the COFF linker. [1] http://lists.llvm.org/pipermail/llvm-dev/2016-April/098832.html Differential Revision: http://reviews.llvm.org/D19752 llvm-svn: 268178
2016-05-01 12:55:03 +08:00
; SHARED-NEXT: Type: Object
[LTO] An interesting case which shows up how we handle common symbols. The gold plugin logic for common symbols is a little bit convoluted as the plugin API has not an explicit way to update the alignment. In gold, then, we need to keep the bitcode symbol @a around because that's the only way to get the alignment right in the final object. In lld, this is not true. We already have all the informations we need about common symbols (size/alignment) so we don't have to keep the existing symbol and pass it to the mover. llvm-svn: 267007
2016-04-22 01:11:39 +08:00
; SHARED-NEXT: Other: 0
; SHARED-NEXT: Section: .bss
; SHARED-NEXT: }