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

24 lines
1.1 KiB
LLVM
Raw Normal View History

LTO: introduce object file-based on-disk module format. This format is simply a regular object file with the bitcode stored in a section named ".llvmbc", plus any number of other (non-allocated) sections. One immediate use case for this is to accommodate compilation processes which expect the object file to contain metadata in non-allocated sections, such as the ".go_export" section used by some Go compilers [1], although I imagine that in the future we could consider compiling parts of the module (such as large non-inlinable functions) directly into the object file to improve LTO efficiency. [1] http://golang.org/doc/install/gccgo#Imports Differential Revision: http://reviews.llvm.org/D4371 llvm-svn: 218078
2014-09-19 05:28:49 +08:00
; RUN: llvm-as -o %T/bcsection.bc %s
; RUN: llvm-mc -I=%T -filetype=obj -triple=x86_64-pc-win32 -o %T/bcsection.coff.bco %p/Inputs/bcsection.s
; RUN: llvm-nm %T/bcsection.coff.bco | FileCheck %s
Try to fix i686-cygming bots. llvm-svn: 218086
2014-09-19 06:56:00 +08:00
; RUN: llvm-lto -exported-symbol=main -exported-symbol=_main -o %T/bcsection.coff.o %T/bcsection.coff.bco
LTO: introduce object file-based on-disk module format. This format is simply a regular object file with the bitcode stored in a section named ".llvmbc", plus any number of other (non-allocated) sections. One immediate use case for this is to accommodate compilation processes which expect the object file to contain metadata in non-allocated sections, such as the ".go_export" section used by some Go compilers [1], although I imagine that in the future we could consider compiling parts of the module (such as large non-inlinable functions) directly into the object file to improve LTO efficiency. [1] http://golang.org/doc/install/gccgo#Imports Differential Revision: http://reviews.llvm.org/D4371 llvm-svn: 218078
2014-09-19 05:28:49 +08:00
; RUN: llvm-nm %T/bcsection.coff.o | FileCheck %s
; RUN: llvm-mc -I=%T -filetype=obj -triple=x86_64-unknown-linux-gnu -o %T/bcsection.elf.bco %p/Inputs/bcsection.s
; RUN: llvm-nm %T/bcsection.elf.bco | FileCheck %s
Try to fix i686-cygming bots. llvm-svn: 218086
2014-09-19 06:56:00 +08:00
; RUN: llvm-lto -exported-symbol=main -exported-symbol=_main -o %T/bcsection.elf.o %T/bcsection.elf.bco
LTO: introduce object file-based on-disk module format. This format is simply a regular object file with the bitcode stored in a section named ".llvmbc", plus any number of other (non-allocated) sections. One immediate use case for this is to accommodate compilation processes which expect the object file to contain metadata in non-allocated sections, such as the ".go_export" section used by some Go compilers [1], although I imagine that in the future we could consider compiling parts of the module (such as large non-inlinable functions) directly into the object file to improve LTO efficiency. [1] http://golang.org/doc/install/gccgo#Imports Differential Revision: http://reviews.llvm.org/D4371 llvm-svn: 218078
2014-09-19 05:28:49 +08:00
; RUN: llvm-nm %T/bcsection.elf.o | FileCheck %s
; RUN: llvm-mc -I=%T -filetype=obj -triple=x86_64-apple-darwin11 -o %T/bcsection.macho.bco %p/Inputs/bcsection.macho.s
; RUN: llvm-nm %T/bcsection.macho.bco | FileCheck %s
Try to fix i686-cygming bots. llvm-svn: 218086
2014-09-19 06:56:00 +08:00
; RUN: llvm-lto -exported-symbol=main -exported-symbol=_main -o %T/bcsection.macho.o %T/bcsection.macho.bco
LTO: introduce object file-based on-disk module format. This format is simply a regular object file with the bitcode stored in a section named ".llvmbc", plus any number of other (non-allocated) sections. One immediate use case for this is to accommodate compilation processes which expect the object file to contain metadata in non-allocated sections, such as the ".go_export" section used by some Go compilers [1], although I imagine that in the future we could consider compiling parts of the module (such as large non-inlinable functions) directly into the object file to improve LTO efficiency. [1] http://golang.org/doc/install/gccgo#Imports Differential Revision: http://reviews.llvm.org/D4371 llvm-svn: 218078
2014-09-19 05:28:49 +08:00
; RUN: llvm-nm %T/bcsection.macho.o | FileCheck %s
Make the default triple optional by allowing an empty string When building LLVM as a (potentially dynamic) library that can be linked against by multiple compilers, the default triple is not really meaningful. We allow to explicitely set it to an empty string when configuring LLVM. In this case, said "target independent" tests in the test suite that are using the default triple are disabled by matching the newly available feature "default_triple". Reviewers: probinson, echristo Differential Revision: http://reviews.llvm.org/D12660 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 247775
2015-09-16 13:34:32 +08:00
; REQUIRES: default_triple
LTO: introduce object file-based on-disk module format. This format is simply a regular object file with the bitcode stored in a section named ".llvmbc", plus any number of other (non-allocated) sections. One immediate use case for this is to accommodate compilation processes which expect the object file to contain metadata in non-allocated sections, such as the ".go_export" section used by some Go compilers [1], although I imagine that in the future we could consider compiling parts of the module (such as large non-inlinable functions) directly into the object file to improve LTO efficiency. [1] http://golang.org/doc/install/gccgo#Imports Differential Revision: http://reviews.llvm.org/D4371 llvm-svn: 218078
2014-09-19 05:28:49 +08:00
; CHECK: main
define i32 @main() {
ret i32 0
}