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

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

58 lines
1.5 KiB
LLVM
Raw Normal View History

CodeGen: Add a target option for emitting .addrsig directives for all address-significant symbols. Differential Revision: https://reviews.llvm.org/D48143 llvm-svn: 337331
2018-07-18 06:40:08 +08:00
; RUN: llc < %s -mtriple=x86_64-unknown-linux | FileCheck --check-prefix=NO-ADDRSIG %s
; RUN: llc < %s -mtriple=x86_64-unknown-linux -addrsig | FileCheck %s
; NO-ADDRSIG-NOT: .addrsig
; CHECK: .addrsig
; CHECK: .addrsig_sym f1
define void @f1() {
CodeGen: Add two more conditions for adding symbols to the address-significance table. Firstly, require the symbol to be used within the module. If a symbol is unused within a module, then by definition it cannot be address-significant within that module. This condition is useful on all platforms because it could make symbol tables smaller -- without this change, emitting an address-significance table could cause otherwise unused undefined symbols to be added to the object file. But this change is necessary with COFF specifically in order to preserve the property that an unreferenced undefined symbol in an IR module does not result in a link failure. This is already the case for ELF because ELF linkers only reject links with unresolved symbols if there is a relocation to that symbol, but COFF linkers require all undefined symbols to be resolved regardless of relocations. So if a module contains an unreferenced undefined symbol, we need to make sure not to add it to the address-significance table (and thus the symbol table) in case it doesn't end up resolved at link time. Secondly, do not add dllimport symbols to the table. These symbols won't be able to be resolved because their definitions live in another module and are accessed via the IAT, and the address-significance table has no effect on other modules anyway. It wouldn't make sense to add the IAT entry symbol to the address-significance table either because the IAT entry isn't address-significant -- the generated code never takes its address. Differential Revision: https://reviews.llvm.org/D51199 llvm-svn: 340648
2018-08-25 04:37:09 +08:00
%f1 = bitcast void()* @f1 to i8*
%f2 = bitcast void()* @f2 to i8*
%f3 = bitcast void()* @f3 to i8*
%g1 = bitcast i32* @g1 to i8*
%g2 = bitcast i32* @g2 to i8*
%g3 = bitcast i32* @g3 to i8*
%dllimport = bitcast i32* @dllimport to i8*
%tls = bitcast i32* @tls to i8*
%a1 = bitcast i32* @a1 to i8*
%a2 = bitcast i32* @a2 to i8*
%i1 = bitcast void()* @i1 to i8*
%i2 = bitcast void()* @i2 to i8*
CodeGen: Add a target option for emitting .addrsig directives for all address-significant symbols. Differential Revision: https://reviews.llvm.org/D48143 llvm-svn: 337331
2018-07-18 06:40:08 +08:00
unreachable
}
; CHECK-NOT: .addrsig_sym f2
define internal void @f2() local_unnamed_addr {
unreachable
}
; CHECK-NOT: .addrsig_sym f3
declare void @f3() unnamed_addr
; CHECK: .addrsig_sym g1
@g1 = global i32 0
; CHECK-NOT: .addrsig_sym g2
@g2 = internal local_unnamed_addr global i32 0
; CHECK-NOT: .addrsig_sym g3
@g3 = external unnamed_addr global i32
CodeGen: Add two more conditions for adding symbols to the address-significance table. Firstly, require the symbol to be used within the module. If a symbol is unused within a module, then by definition it cannot be address-significant within that module. This condition is useful on all platforms because it could make symbol tables smaller -- without this change, emitting an address-significance table could cause otherwise unused undefined symbols to be added to the object file. But this change is necessary with COFF specifically in order to preserve the property that an unreferenced undefined symbol in an IR module does not result in a link failure. This is already the case for ELF because ELF linkers only reject links with unresolved symbols if there is a relocation to that symbol, but COFF linkers require all undefined symbols to be resolved regardless of relocations. So if a module contains an unreferenced undefined symbol, we need to make sure not to add it to the address-significance table (and thus the symbol table) in case it doesn't end up resolved at link time. Secondly, do not add dllimport symbols to the table. These symbols won't be able to be resolved because their definitions live in another module and are accessed via the IAT, and the address-significance table has no effect on other modules anyway. It wouldn't make sense to add the IAT entry symbol to the address-significance table either because the IAT entry isn't address-significant -- the generated code never takes its address. Differential Revision: https://reviews.llvm.org/D51199 llvm-svn: 340648
2018-08-25 04:37:09 +08:00
; CHECK-NOT: .addrsig_sym unref
@unref = external global i32
; CHECK-NOT: .addrsig_sym dllimport
@dllimport = external dllimport global i32
CodeGen: Don't create address significance table entries for thread-local variables. The presence of these symbols in the symbol table can cause symbol type mismatch errors (or undefined symbol errors on emulated TLS targets) and they can't be ICF'd anyway. llvm-svn: 337338
2018-07-18 08:21:40 +08:00
; CHECK-NOT: .addrsig_sym tls
@tls = thread_local global i32 0
CodeGen: Add a target option for emitting .addrsig directives for all address-significant symbols. Differential Revision: https://reviews.llvm.org/D48143 llvm-svn: 337331
2018-07-18 06:40:08 +08:00
; CHECK: .addrsig_sym a1
@a1 = alias i32, i32* @g1
; CHECK-NOT: .addrsig_sym a2
@a2 = internal local_unnamed_addr alias i32, i32* @g2
; CHECK: .addrsig_sym i1
@i1 = ifunc void(), void()* @f1
; CHECK-NOT: .addrsig_sym i2
@i2 = internal local_unnamed_addr ifunc void(), void()* @f2