Implement LTO
This commit implements LTO for rust leveraging LLVM's passes. What this means
is:
* When compiling an rlib, in addition to insdering foo.o into the archive, also
insert foo.bc (the LLVM bytecode) of the optimized module.
* When the compiler detects the -Z lto option, it will attempt to perform LTO on
a staticlib or binary output. The compiler will emit an error if a dylib or
rlib output is being generated.
* The actual act of performing LTO is as follows:
1. Force all upstream libraries to have an rlib version available.
2. Load the bytecode of each upstream library from the rlib.
3. Link all this bytecode into the current LLVM module (just using llvm
apis)
4. Run an internalization pass which internalizes all symbols except those
found reachable for the local crate of compilation.
5. Run the LLVM LTO pass manager over this entire module
6a. If assembling an archive, then add all upstream rlibs into the output
archive. This ignores all of the object/bitcode/metadata files rust
generated and placed inside the rlibs.
6b. If linking a binary, create copies of all upstream rlibs, remove the
rust-generated object-file, and then link everything as usual.
As I have explained in #10741, this process is excruciatingly slow, so this is
*not* turned on by default, and it is also why I have decided to hide it behind
a -Z flag for now. The good news is that the binary sizes are about as small as
they can be as a result of LTO, so it's definitely working.
Closes #10741
Closes #10740
2013-12-02 23:19:29 -08:00
|
|
|
// Copyright 2013 The Rust Project Developers. See the COPYRIGHT
|
|
|
|
// file at the top-level directory of this distribution and at
|
|
|
|
// http://rust-lang.org/COPYRIGHT.
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
|
|
|
|
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
|
|
|
|
// option. This file may not be copied, modified, or distributed
|
|
|
|
// except according to those terms.
|
|
|
|
|
2016-11-30 10:03:42 -05:00
|
|
|
use back::link;
|
|
|
|
use back::write;
|
|
|
|
use back::symbol_export::{self, ExportedSymbols};
|
2015-01-03 22:42:21 -05:00
|
|
|
use rustc::session::{self, config};
|
2014-07-07 17:58:01 -07:00
|
|
|
use llvm;
|
2014-07-06 21:43:22 -07:00
|
|
|
use llvm::archive_ro::ArchiveRO;
|
2014-07-07 17:58:01 -07:00
|
|
|
use llvm::{ModuleRef, TargetMachineRef, True, False};
|
2014-11-15 20:30:33 -05:00
|
|
|
use rustc::util::common::time;
|
2015-09-22 00:33:17 +09:00
|
|
|
use rustc::util::common::path2cstr;
|
2016-11-30 10:03:42 -05:00
|
|
|
use rustc::hir::def_id::LOCAL_CRATE;
|
2015-07-22 16:22:51 -07:00
|
|
|
use back::write::{ModuleConfig, with_llvm_pmb};
|
Implement LTO
This commit implements LTO for rust leveraging LLVM's passes. What this means
is:
* When compiling an rlib, in addition to insdering foo.o into the archive, also
insert foo.bc (the LLVM bytecode) of the optimized module.
* When the compiler detects the -Z lto option, it will attempt to perform LTO on
a staticlib or binary output. The compiler will emit an error if a dylib or
rlib output is being generated.
* The actual act of performing LTO is as follows:
1. Force all upstream libraries to have an rlib version available.
2. Load the bytecode of each upstream library from the rlib.
3. Link all this bytecode into the current LLVM module (just using llvm
apis)
4. Run an internalization pass which internalizes all symbols except those
found reachable for the local crate of compilation.
5. Run the LLVM LTO pass manager over this entire module
6a. If assembling an archive, then add all upstream rlibs into the output
archive. This ignores all of the object/bitcode/metadata files rust
generated and placed inside the rlibs.
6b. If linking a binary, create copies of all upstream rlibs, remove the
rust-generated object-file, and then link everything as usual.
As I have explained in #10741, this process is excruciatingly slow, so this is
*not* turned on by default, and it is also why I have decided to hide it behind
a -Z flag for now. The good news is that the binary sizes are about as small as
they can be as a result of LTO, so it's definitely working.
Closes #10741
Closes #10740
2013-12-02 23:19:29 -08:00
|
|
|
|
2014-02-26 12:58:41 -05:00
|
|
|
use libc;
|
2017-06-08 14:10:36 -07:00
|
|
|
use flate2::read::ZlibDecoder;
|
Implement LTO
This commit implements LTO for rust leveraging LLVM's passes. What this means
is:
* When compiling an rlib, in addition to insdering foo.o into the archive, also
insert foo.bc (the LLVM bytecode) of the optimized module.
* When the compiler detects the -Z lto option, it will attempt to perform LTO on
a staticlib or binary output. The compiler will emit an error if a dylib or
rlib output is being generated.
* The actual act of performing LTO is as follows:
1. Force all upstream libraries to have an rlib version available.
2. Load the bytecode of each upstream library from the rlib.
3. Link all this bytecode into the current LLVM module (just using llvm
apis)
4. Run an internalization pass which internalizes all symbols except those
found reachable for the local crate of compilation.
5. Run the LLVM LTO pass manager over this entire module
6a. If assembling an archive, then add all upstream rlibs into the output
archive. This ignores all of the object/bitcode/metadata files rust
generated and placed inside the rlibs.
6b. If linking a binary, create copies of all upstream rlibs, remove the
rust-generated object-file, and then link everything as usual.
As I have explained in #10741, this process is excruciatingly slow, so this is
*not* turned on by default, and it is also why I have decided to hide it behind
a -Z flag for now. The good news is that the binary sizes are about as small as
they can be as a result of LTO, so it's definitely working.
Closes #10741
Closes #10740
2013-12-02 23:19:29 -08:00
|
|
|
|
2017-06-08 14:10:36 -07:00
|
|
|
use std::io::Read;
|
2014-11-25 13:28:35 -08:00
|
|
|
use std::ffi::CString;
|
2016-05-13 20:48:32 -04:00
|
|
|
use std::path::Path;
|
2014-07-31 15:05:08 +02:00
|
|
|
|
2016-11-30 10:03:42 -05:00
|
|
|
pub fn crate_type_allows_lto(crate_type: config::CrateType) -> bool {
|
|
|
|
match crate_type {
|
|
|
|
config::CrateTypeExecutable |
|
|
|
|
config::CrateTypeStaticlib |
|
|
|
|
config::CrateTypeCdylib => true,
|
|
|
|
|
|
|
|
config::CrateTypeDylib |
|
|
|
|
config::CrateTypeRlib |
|
|
|
|
config::CrateTypeProcMacro => false,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn run(sess: &session::Session,
|
|
|
|
llmod: ModuleRef,
|
|
|
|
tm: TargetMachineRef,
|
|
|
|
exported_symbols: &ExportedSymbols,
|
2015-09-22 00:33:17 +09:00
|
|
|
config: &ModuleConfig,
|
2016-05-13 20:48:32 -04:00
|
|
|
temp_no_opt_bc_filename: &Path) {
|
2014-02-06 19:57:09 -08:00
|
|
|
if sess.opts.cg.prefer_dynamic {
|
2015-12-21 10:00:43 +13:00
|
|
|
sess.struct_err("cannot prefer dynamic linking when performing LTO")
|
2016-05-10 14:17:57 -07:00
|
|
|
.note("only 'staticlib', 'bin', and 'cdylib' outputs are \
|
|
|
|
supported with LTO")
|
2015-12-21 10:00:43 +13:00
|
|
|
.emit();
|
2013-12-26 22:27:06 -08:00
|
|
|
sess.abort_if_errors();
|
|
|
|
}
|
|
|
|
|
Implement LTO
This commit implements LTO for rust leveraging LLVM's passes. What this means
is:
* When compiling an rlib, in addition to insdering foo.o into the archive, also
insert foo.bc (the LLVM bytecode) of the optimized module.
* When the compiler detects the -Z lto option, it will attempt to perform LTO on
a staticlib or binary output. The compiler will emit an error if a dylib or
rlib output is being generated.
* The actual act of performing LTO is as follows:
1. Force all upstream libraries to have an rlib version available.
2. Load the bytecode of each upstream library from the rlib.
3. Link all this bytecode into the current LLVM module (just using llvm
apis)
4. Run an internalization pass which internalizes all symbols except those
found reachable for the local crate of compilation.
5. Run the LLVM LTO pass manager over this entire module
6a. If assembling an archive, then add all upstream rlibs into the output
archive. This ignores all of the object/bitcode/metadata files rust
generated and placed inside the rlibs.
6b. If linking a binary, create copies of all upstream rlibs, remove the
rust-generated object-file, and then link everything as usual.
As I have explained in #10741, this process is excruciatingly slow, so this is
*not* turned on by default, and it is also why I have decided to hide it behind
a -Z flag for now. The good news is that the binary sizes are about as small as
they can be as a result of LTO, so it's definitely working.
Closes #10741
Closes #10740
2013-12-02 23:19:29 -08:00
|
|
|
// Make sure we actually can run LTO
|
2015-06-11 13:56:07 +01:00
|
|
|
for crate_type in sess.crate_types.borrow().iter() {
|
2016-11-30 10:03:42 -05:00
|
|
|
if !crate_type_allows_lto(*crate_type) {
|
2016-12-02 18:02:14 -05:00
|
|
|
sess.fatal("lto can only be run for executables, cdylibs and \
|
Implement LTO
This commit implements LTO for rust leveraging LLVM's passes. What this means
is:
* When compiling an rlib, in addition to insdering foo.o into the archive, also
insert foo.bc (the LLVM bytecode) of the optimized module.
* When the compiler detects the -Z lto option, it will attempt to perform LTO on
a staticlib or binary output. The compiler will emit an error if a dylib or
rlib output is being generated.
* The actual act of performing LTO is as follows:
1. Force all upstream libraries to have an rlib version available.
2. Load the bytecode of each upstream library from the rlib.
3. Link all this bytecode into the current LLVM module (just using llvm
apis)
4. Run an internalization pass which internalizes all symbols except those
found reachable for the local crate of compilation.
5. Run the LLVM LTO pass manager over this entire module
6a. If assembling an archive, then add all upstream rlibs into the output
archive. This ignores all of the object/bitcode/metadata files rust
generated and placed inside the rlibs.
6b. If linking a binary, create copies of all upstream rlibs, remove the
rust-generated object-file, and then link everything as usual.
As I have explained in #10741, this process is excruciatingly slow, so this is
*not* turned on by default, and it is also why I have decided to hide it behind
a -Z flag for now. The good news is that the binary sizes are about as small as
they can be as a result of LTO, so it's definitely working.
Closes #10741
Closes #10740
2013-12-02 23:19:29 -08:00
|
|
|
static library outputs");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-11-30 10:03:42 -05:00
|
|
|
let export_threshold =
|
2017-03-24 09:31:26 +01:00
|
|
|
symbol_export::crates_export_threshold(&sess.crate_types.borrow());
|
2016-11-30 10:03:42 -05:00
|
|
|
|
|
|
|
let symbol_filter = &|&(ref name, level): &(String, _)| {
|
|
|
|
if symbol_export::is_below_threshold(level, export_threshold) {
|
|
|
|
let mut bytes = Vec::with_capacity(name.len() + 1);
|
|
|
|
bytes.extend(name.bytes());
|
|
|
|
Some(CString::new(bytes).unwrap())
|
|
|
|
} else {
|
|
|
|
None
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
let mut symbol_white_list: Vec<CString> = exported_symbols
|
|
|
|
.exported_symbols(LOCAL_CRATE)
|
|
|
|
.iter()
|
|
|
|
.filter_map(symbol_filter)
|
|
|
|
.collect();
|
|
|
|
|
Implement LTO
This commit implements LTO for rust leveraging LLVM's passes. What this means
is:
* When compiling an rlib, in addition to insdering foo.o into the archive, also
insert foo.bc (the LLVM bytecode) of the optimized module.
* When the compiler detects the -Z lto option, it will attempt to perform LTO on
a staticlib or binary output. The compiler will emit an error if a dylib or
rlib output is being generated.
* The actual act of performing LTO is as follows:
1. Force all upstream libraries to have an rlib version available.
2. Load the bytecode of each upstream library from the rlib.
3. Link all this bytecode into the current LLVM module (just using llvm
apis)
4. Run an internalization pass which internalizes all symbols except those
found reachable for the local crate of compilation.
5. Run the LLVM LTO pass manager over this entire module
6a. If assembling an archive, then add all upstream rlibs into the output
archive. This ignores all of the object/bitcode/metadata files rust
generated and placed inside the rlibs.
6b. If linking a binary, create copies of all upstream rlibs, remove the
rust-generated object-file, and then link everything as usual.
As I have explained in #10741, this process is excruciatingly slow, so this is
*not* turned on by default, and it is also why I have decided to hide it behind
a -Z flag for now. The good news is that the binary sizes are about as small as
they can be as a result of LTO, so it's definitely working.
Closes #10741
Closes #10740
2013-12-02 23:19:29 -08:00
|
|
|
// For each of our upstream dependencies, find the corresponding rlib and
|
|
|
|
// load the bitcode from the archive. Then merge it into the current LLVM
|
|
|
|
// module that we've got.
|
2016-08-12 21:15:42 -05:00
|
|
|
link::each_linked_rlib(sess, &mut |cnum, path| {
|
|
|
|
// `#![no_builtins]` crates don't participate in LTO.
|
2016-08-14 21:56:26 -05:00
|
|
|
if sess.cstore.is_no_builtins(cnum) {
|
2016-08-12 21:15:42 -05:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2016-11-30 10:03:42 -05:00
|
|
|
symbol_white_list.extend(
|
|
|
|
exported_symbols.exported_symbols(cnum)
|
|
|
|
.iter()
|
|
|
|
.filter_map(symbol_filter));
|
|
|
|
|
2013-12-16 20:58:21 -08:00
|
|
|
let archive = ArchiveRO::open(&path).expect("wanted an rlib");
|
2015-07-07 21:33:44 -07:00
|
|
|
let bytecodes = archive.iter().filter_map(|child| {
|
2015-10-22 22:07:19 -07:00
|
|
|
child.ok().and_then(|c| c.name().map(|name| (name, c)))
|
2015-07-07 21:33:44 -07:00
|
|
|
}).filter(|&(name, _)| name.ends_with("bytecode.deflate"));
|
|
|
|
for (name, data) in bytecodes {
|
|
|
|
let bc_encoded = data.data();
|
2014-12-09 11:00:41 -05:00
|
|
|
|
|
|
|
let bc_decoded = if is_versioned_bytecode_format(bc_encoded) {
|
2015-06-25 10:07:01 -07:00
|
|
|
time(sess.time_passes(), &format!("decode {}", name), || {
|
2014-09-17 16:18:12 -07:00
|
|
|
// Read the version
|
|
|
|
let version = extract_bytecode_format_version(bc_encoded);
|
2014-07-31 15:05:08 +02:00
|
|
|
|
2014-09-17 16:18:12 -07:00
|
|
|
if version == 1 {
|
|
|
|
// The only version existing so far
|
|
|
|
let data_size = extract_compressed_bytecode_size_v1(bc_encoded);
|
2015-01-07 11:58:31 -05:00
|
|
|
let compressed_data = &bc_encoded[
|
2014-09-24 23:41:09 +12:00
|
|
|
link::RLIB_BYTECODE_OBJECT_V1_DATA_OFFSET..
|
2015-03-25 17:06:52 -07:00
|
|
|
(link::RLIB_BYTECODE_OBJECT_V1_DATA_OFFSET + data_size as usize)];
|
2014-07-31 15:05:08 +02:00
|
|
|
|
2017-06-08 14:10:36 -07:00
|
|
|
let mut inflated = Vec::new();
|
|
|
|
let res = ZlibDecoder::new(compressed_data)
|
|
|
|
.read_to_end(&mut inflated);
|
|
|
|
if res.is_err() {
|
|
|
|
sess.fatal(&format!("failed to decompress bc of `{}`",
|
|
|
|
name))
|
2014-09-17 16:18:12 -07:00
|
|
|
}
|
2017-06-08 14:10:36 -07:00
|
|
|
inflated
|
2014-09-17 16:18:12 -07:00
|
|
|
} else {
|
2015-01-07 11:58:31 -05:00
|
|
|
sess.fatal(&format!("Unsupported bytecode format version {}",
|
2015-02-20 14:08:14 -05:00
|
|
|
version))
|
2014-09-17 16:18:12 -07:00
|
|
|
}
|
2014-12-09 11:00:41 -05:00
|
|
|
})
|
2014-09-17 16:18:12 -07:00
|
|
|
} else {
|
2015-06-25 10:07:01 -07:00
|
|
|
time(sess.time_passes(), &format!("decode {}", name), || {
|
|
|
|
// the object must be in the old, pre-versioning format, so
|
|
|
|
// simply inflate everything and let LLVM decide if it can
|
|
|
|
// make sense of it
|
2017-06-08 14:10:36 -07:00
|
|
|
let mut inflated = Vec::new();
|
|
|
|
let res = ZlibDecoder::new(bc_encoded)
|
|
|
|
.read_to_end(&mut inflated);
|
|
|
|
if res.is_err() {
|
|
|
|
sess.fatal(&format!("failed to decompress bc of `{}`",
|
|
|
|
name))
|
2014-07-31 15:05:08 +02:00
|
|
|
}
|
2017-06-08 14:10:36 -07:00
|
|
|
inflated
|
2014-12-09 11:00:41 -05:00
|
|
|
})
|
2014-09-17 16:18:12 -07:00
|
|
|
};
|
2014-07-31 15:05:08 +02:00
|
|
|
|
2015-01-26 21:21:15 -05:00
|
|
|
let ptr = bc_decoded.as_ptr();
|
2015-07-07 21:33:44 -07:00
|
|
|
debug!("linking {}", name);
|
2015-06-25 10:07:01 -07:00
|
|
|
time(sess.time_passes(), &format!("ll link {}", name), || unsafe {
|
2014-09-17 16:18:12 -07:00
|
|
|
if !llvm::LLVMRustLinkInExternalBitcode(llmod,
|
|
|
|
ptr as *const libc::c_char,
|
|
|
|
bc_decoded.len() as libc::size_t) {
|
2015-12-14 11:17:55 +13:00
|
|
|
write::llvm_err(sess.diagnostic(),
|
2014-09-17 16:18:12 -07:00
|
|
|
format!("failed to load bc of `{}`",
|
2017-03-24 09:31:26 +01:00
|
|
|
name));
|
2014-09-17 16:18:12 -07:00
|
|
|
}
|
|
|
|
});
|
|
|
|
}
|
2015-06-25 10:07:01 -07:00
|
|
|
});
|
Implement LTO
This commit implements LTO for rust leveraging LLVM's passes. What this means
is:
* When compiling an rlib, in addition to insdering foo.o into the archive, also
insert foo.bc (the LLVM bytecode) of the optimized module.
* When the compiler detects the -Z lto option, it will attempt to perform LTO on
a staticlib or binary output. The compiler will emit an error if a dylib or
rlib output is being generated.
* The actual act of performing LTO is as follows:
1. Force all upstream libraries to have an rlib version available.
2. Load the bytecode of each upstream library from the rlib.
3. Link all this bytecode into the current LLVM module (just using llvm
apis)
4. Run an internalization pass which internalizes all symbols except those
found reachable for the local crate of compilation.
5. Run the LLVM LTO pass manager over this entire module
6a. If assembling an archive, then add all upstream rlibs into the output
archive. This ignores all of the object/bitcode/metadata files rust
generated and placed inside the rlibs.
6b. If linking a binary, create copies of all upstream rlibs, remove the
rust-generated object-file, and then link everything as usual.
As I have explained in #10741, this process is excruciatingly slow, so this is
*not* turned on by default, and it is also why I have decided to hide it behind
a -Z flag for now. The good news is that the binary sizes are about as small as
they can be as a result of LTO, so it's definitely working.
Closes #10741
Closes #10740
2013-12-02 23:19:29 -08:00
|
|
|
|
2016-11-28 18:05:53 -05:00
|
|
|
// Internalize everything but the exported symbols of the current module
|
2016-11-30 10:03:42 -05:00
|
|
|
let arr: Vec<*const libc::c_char> = symbol_white_list.iter()
|
|
|
|
.map(|c| c.as_ptr())
|
|
|
|
.collect();
|
2013-12-15 23:35:12 +11:00
|
|
|
let ptr = arr.as_ptr();
|
Implement LTO
This commit implements LTO for rust leveraging LLVM's passes. What this means
is:
* When compiling an rlib, in addition to insdering foo.o into the archive, also
insert foo.bc (the LLVM bytecode) of the optimized module.
* When the compiler detects the -Z lto option, it will attempt to perform LTO on
a staticlib or binary output. The compiler will emit an error if a dylib or
rlib output is being generated.
* The actual act of performing LTO is as follows:
1. Force all upstream libraries to have an rlib version available.
2. Load the bytecode of each upstream library from the rlib.
3. Link all this bytecode into the current LLVM module (just using llvm
apis)
4. Run an internalization pass which internalizes all symbols except those
found reachable for the local crate of compilation.
5. Run the LLVM LTO pass manager over this entire module
6a. If assembling an archive, then add all upstream rlibs into the output
archive. This ignores all of the object/bitcode/metadata files rust
generated and placed inside the rlibs.
6b. If linking a binary, create copies of all upstream rlibs, remove the
rust-generated object-file, and then link everything as usual.
As I have explained in #10741, this process is excruciatingly slow, so this is
*not* turned on by default, and it is also why I have decided to hide it behind
a -Z flag for now. The good news is that the binary sizes are about as small as
they can be as a result of LTO, so it's definitely working.
Closes #10741
Closes #10740
2013-12-02 23:19:29 -08:00
|
|
|
unsafe {
|
2014-06-25 12:47:34 -07:00
|
|
|
llvm::LLVMRustRunRestrictionPass(llmod,
|
|
|
|
ptr as *const *const libc::c_char,
|
Implement LTO
This commit implements LTO for rust leveraging LLVM's passes. What this means
is:
* When compiling an rlib, in addition to insdering foo.o into the archive, also
insert foo.bc (the LLVM bytecode) of the optimized module.
* When the compiler detects the -Z lto option, it will attempt to perform LTO on
a staticlib or binary output. The compiler will emit an error if a dylib or
rlib output is being generated.
* The actual act of performing LTO is as follows:
1. Force all upstream libraries to have an rlib version available.
2. Load the bytecode of each upstream library from the rlib.
3. Link all this bytecode into the current LLVM module (just using llvm
apis)
4. Run an internalization pass which internalizes all symbols except those
found reachable for the local crate of compilation.
5. Run the LLVM LTO pass manager over this entire module
6a. If assembling an archive, then add all upstream rlibs into the output
archive. This ignores all of the object/bitcode/metadata files rust
generated and placed inside the rlibs.
6b. If linking a binary, create copies of all upstream rlibs, remove the
rust-generated object-file, and then link everything as usual.
As I have explained in #10741, this process is excruciatingly slow, so this is
*not* turned on by default, and it is also why I have decided to hide it behind
a -Z flag for now. The good news is that the binary sizes are about as small as
they can be as a result of LTO, so it's definitely working.
Closes #10741
Closes #10740
2013-12-02 23:19:29 -08:00
|
|
|
arr.len() as libc::size_t);
|
|
|
|
}
|
|
|
|
|
2013-12-10 23:27:15 -08:00
|
|
|
if sess.no_landing_pads() {
|
|
|
|
unsafe {
|
|
|
|
llvm::LLVMRustMarkAllFunctionsNounwind(llmod);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-09-22 00:33:17 +09:00
|
|
|
if sess.opts.cg.save_temps {
|
2016-05-13 20:48:32 -04:00
|
|
|
let cstr = path2cstr(temp_no_opt_bc_filename);
|
2015-09-22 00:33:17 +09:00
|
|
|
unsafe {
|
|
|
|
llvm::LLVMWriteBitcodeToFile(llmod, cstr.as_ptr());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Implement LTO
This commit implements LTO for rust leveraging LLVM's passes. What this means
is:
* When compiling an rlib, in addition to insdering foo.o into the archive, also
insert foo.bc (the LLVM bytecode) of the optimized module.
* When the compiler detects the -Z lto option, it will attempt to perform LTO on
a staticlib or binary output. The compiler will emit an error if a dylib or
rlib output is being generated.
* The actual act of performing LTO is as follows:
1. Force all upstream libraries to have an rlib version available.
2. Load the bytecode of each upstream library from the rlib.
3. Link all this bytecode into the current LLVM module (just using llvm
apis)
4. Run an internalization pass which internalizes all symbols except those
found reachable for the local crate of compilation.
5. Run the LLVM LTO pass manager over this entire module
6a. If assembling an archive, then add all upstream rlibs into the output
archive. This ignores all of the object/bitcode/metadata files rust
generated and placed inside the rlibs.
6b. If linking a binary, create copies of all upstream rlibs, remove the
rust-generated object-file, and then link everything as usual.
As I have explained in #10741, this process is excruciatingly slow, so this is
*not* turned on by default, and it is also why I have decided to hide it behind
a -Z flag for now. The good news is that the binary sizes are about as small as
they can be as a result of LTO, so it's definitely working.
Closes #10741
Closes #10740
2013-12-02 23:19:29 -08:00
|
|
|
// Now we have one massive module inside of llmod. Time to run the
|
|
|
|
// LTO-specific optimization passes that LLVM provides.
|
|
|
|
//
|
|
|
|
// This code is based off the code found in llvm's LTO code generator:
|
|
|
|
// tools/lto/LTOCodeGenerator.cpp
|
|
|
|
debug!("running the pass manager");
|
|
|
|
unsafe {
|
|
|
|
let pm = llvm::LLVMCreatePassManager();
|
|
|
|
llvm::LLVMRustAddAnalysisPasses(tm, pm, llmod);
|
2016-01-24 20:22:24 -05:00
|
|
|
let pass = llvm::LLVMRustFindAndCreatePass("verify\0".as_ptr() as *const _);
|
|
|
|
assert!(!pass.is_null());
|
|
|
|
llvm::LLVMRustAddPass(pm, pass);
|
Implement LTO
This commit implements LTO for rust leveraging LLVM's passes. What this means
is:
* When compiling an rlib, in addition to insdering foo.o into the archive, also
insert foo.bc (the LLVM bytecode) of the optimized module.
* When the compiler detects the -Z lto option, it will attempt to perform LTO on
a staticlib or binary output. The compiler will emit an error if a dylib or
rlib output is being generated.
* The actual act of performing LTO is as follows:
1. Force all upstream libraries to have an rlib version available.
2. Load the bytecode of each upstream library from the rlib.
3. Link all this bytecode into the current LLVM module (just using llvm
apis)
4. Run an internalization pass which internalizes all symbols except those
found reachable for the local crate of compilation.
5. Run the LLVM LTO pass manager over this entire module
6a. If assembling an archive, then add all upstream rlibs into the output
archive. This ignores all of the object/bitcode/metadata files rust
generated and placed inside the rlibs.
6b. If linking a binary, create copies of all upstream rlibs, remove the
rust-generated object-file, and then link everything as usual.
As I have explained in #10741, this process is excruciatingly slow, so this is
*not* turned on by default, and it is also why I have decided to hide it behind
a -Z flag for now. The good news is that the binary sizes are about as small as
they can be as a result of LTO, so it's definitely working.
Closes #10741
Closes #10740
2013-12-02 23:19:29 -08:00
|
|
|
|
2015-07-22 16:22:51 -07:00
|
|
|
with_llvm_pmb(llmod, config, &mut |b| {
|
|
|
|
llvm::LLVMPassManagerBuilderPopulateLTOPassManager(b, pm,
|
|
|
|
/* Internalize = */ False,
|
|
|
|
/* RunInliner = */ True);
|
|
|
|
});
|
Implement LTO
This commit implements LTO for rust leveraging LLVM's passes. What this means
is:
* When compiling an rlib, in addition to insdering foo.o into the archive, also
insert foo.bc (the LLVM bytecode) of the optimized module.
* When the compiler detects the -Z lto option, it will attempt to perform LTO on
a staticlib or binary output. The compiler will emit an error if a dylib or
rlib output is being generated.
* The actual act of performing LTO is as follows:
1. Force all upstream libraries to have an rlib version available.
2. Load the bytecode of each upstream library from the rlib.
3. Link all this bytecode into the current LLVM module (just using llvm
apis)
4. Run an internalization pass which internalizes all symbols except those
found reachable for the local crate of compilation.
5. Run the LLVM LTO pass manager over this entire module
6a. If assembling an archive, then add all upstream rlibs into the output
archive. This ignores all of the object/bitcode/metadata files rust
generated and placed inside the rlibs.
6b. If linking a binary, create copies of all upstream rlibs, remove the
rust-generated object-file, and then link everything as usual.
As I have explained in #10741, this process is excruciatingly slow, so this is
*not* turned on by default, and it is also why I have decided to hide it behind
a -Z flag for now. The good news is that the binary sizes are about as small as
they can be as a result of LTO, so it's definitely working.
Closes #10741
Closes #10740
2013-12-02 23:19:29 -08:00
|
|
|
|
2016-01-24 20:22:24 -05:00
|
|
|
let pass = llvm::LLVMRustFindAndCreatePass("verify\0".as_ptr() as *const _);
|
|
|
|
assert!(!pass.is_null());
|
|
|
|
llvm::LLVMRustAddPass(pm, pass);
|
Implement LTO
This commit implements LTO for rust leveraging LLVM's passes. What this means
is:
* When compiling an rlib, in addition to insdering foo.o into the archive, also
insert foo.bc (the LLVM bytecode) of the optimized module.
* When the compiler detects the -Z lto option, it will attempt to perform LTO on
a staticlib or binary output. The compiler will emit an error if a dylib or
rlib output is being generated.
* The actual act of performing LTO is as follows:
1. Force all upstream libraries to have an rlib version available.
2. Load the bytecode of each upstream library from the rlib.
3. Link all this bytecode into the current LLVM module (just using llvm
apis)
4. Run an internalization pass which internalizes all symbols except those
found reachable for the local crate of compilation.
5. Run the LLVM LTO pass manager over this entire module
6a. If assembling an archive, then add all upstream rlibs into the output
archive. This ignores all of the object/bitcode/metadata files rust
generated and placed inside the rlibs.
6b. If linking a binary, create copies of all upstream rlibs, remove the
rust-generated object-file, and then link everything as usual.
As I have explained in #10741, this process is excruciatingly slow, so this is
*not* turned on by default, and it is also why I have decided to hide it behind
a -Z flag for now. The good news is that the binary sizes are about as small as
they can be as a result of LTO, so it's definitely working.
Closes #10741
Closes #10740
2013-12-02 23:19:29 -08:00
|
|
|
|
2015-06-25 10:07:01 -07:00
|
|
|
time(sess.time_passes(), "LTO passes", ||
|
Implement LTO
This commit implements LTO for rust leveraging LLVM's passes. What this means
is:
* When compiling an rlib, in addition to insdering foo.o into the archive, also
insert foo.bc (the LLVM bytecode) of the optimized module.
* When the compiler detects the -Z lto option, it will attempt to perform LTO on
a staticlib or binary output. The compiler will emit an error if a dylib or
rlib output is being generated.
* The actual act of performing LTO is as follows:
1. Force all upstream libraries to have an rlib version available.
2. Load the bytecode of each upstream library from the rlib.
3. Link all this bytecode into the current LLVM module (just using llvm
apis)
4. Run an internalization pass which internalizes all symbols except those
found reachable for the local crate of compilation.
5. Run the LLVM LTO pass manager over this entire module
6a. If assembling an archive, then add all upstream rlibs into the output
archive. This ignores all of the object/bitcode/metadata files rust
generated and placed inside the rlibs.
6b. If linking a binary, create copies of all upstream rlibs, remove the
rust-generated object-file, and then link everything as usual.
As I have explained in #10741, this process is excruciatingly slow, so this is
*not* turned on by default, and it is also why I have decided to hide it behind
a -Z flag for now. The good news is that the binary sizes are about as small as
they can be as a result of LTO, so it's definitely working.
Closes #10741
Closes #10740
2013-12-02 23:19:29 -08:00
|
|
|
llvm::LLVMRunPassManager(pm, llmod));
|
|
|
|
|
|
|
|
llvm::LLVMDisposePassManager(pm);
|
|
|
|
}
|
|
|
|
debug!("lto done");
|
|
|
|
}
|
2014-07-31 15:05:08 +02:00
|
|
|
|
|
|
|
fn is_versioned_bytecode_format(bc: &[u8]) -> bool {
|
|
|
|
let magic_id_byte_count = link::RLIB_BYTECODE_OBJECT_MAGIC.len();
|
|
|
|
return bc.len() > magic_id_byte_count &&
|
2015-01-12 16:59:18 -05:00
|
|
|
&bc[..magic_id_byte_count] == link::RLIB_BYTECODE_OBJECT_MAGIC;
|
2014-07-31 15:05:08 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
fn extract_bytecode_format_version(bc: &[u8]) -> u32 {
|
2015-04-17 15:32:42 -07:00
|
|
|
let pos = link::RLIB_BYTECODE_OBJECT_VERSION_OFFSET;
|
|
|
|
let byte_data = &bc[pos..pos + 4];
|
|
|
|
let data = unsafe { *(byte_data.as_ptr() as *const u32) };
|
|
|
|
u32::from_le(data)
|
2014-07-31 15:05:08 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
fn extract_compressed_bytecode_size_v1(bc: &[u8]) -> u64 {
|
2015-04-17 15:32:42 -07:00
|
|
|
let pos = link::RLIB_BYTECODE_OBJECT_V1_DATASIZE_OFFSET;
|
|
|
|
let byte_data = &bc[pos..pos + 8];
|
|
|
|
let data = unsafe { *(byte_data.as_ptr() as *const u64) };
|
|
|
|
u64::from_le(data)
|
2014-07-31 15:05:08 +02:00
|
|
|
}
|