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-03 01:19:29 -06: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.
|
|
|
|
|
2014-07-04 21:41:54 -05:00
|
|
|
use super::link;
|
2014-08-11 12:33:58 -05:00
|
|
|
use super::write;
|
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-03 01:19:29 -06:00
|
|
|
use driver::session;
|
2014-05-06 06:38:01 -05:00
|
|
|
use driver::config;
|
2014-07-07 19:58:01 -05:00
|
|
|
use llvm;
|
2014-07-06 23:43:22 -05:00
|
|
|
use llvm::archive_ro::ArchiveRO;
|
2014-07-07 19:58:01 -05:00
|
|
|
use llvm::{ModuleRef, TargetMachineRef, True, False};
|
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-03 01:19:29 -06:00
|
|
|
use metadata::cstore;
|
|
|
|
use util::common::time;
|
|
|
|
|
2014-02-26 11:58:41 -06:00
|
|
|
use libc;
|
2014-02-21 12:54:00 -06:00
|
|
|
use flate;
|
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-03 01:19:29 -06:00
|
|
|
|
2014-09-17 18:18:12 -05:00
|
|
|
use std::iter;
|
2014-07-31 08:05:08 -05:00
|
|
|
use std::mem;
|
|
|
|
|
2014-03-05 08:36:01 -06:00
|
|
|
pub fn run(sess: &session::Session, llmod: ModuleRef,
|
2014-05-22 18:57:53 -05:00
|
|
|
tm: TargetMachineRef, reachable: &[String]) {
|
2014-02-06 21:57:09 -06:00
|
|
|
if sess.opts.cg.prefer_dynamic {
|
2013-12-27 00:27:06 -06:00
|
|
|
sess.err("cannot prefer dynamic linking when performing LTO");
|
|
|
|
sess.note("only 'staticlib' and 'bin' outputs are supported with LTO");
|
|
|
|
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-03 01:19:29 -06:00
|
|
|
// Make sure we actually can run LTO
|
2014-03-20 21:49:20 -05:00
|
|
|
for crate_type in sess.crate_types.borrow().iter() {
|
Redesign output flags for rustc
This commit removes the -c, --emit-llvm, -s, --rlib, --dylib, --staticlib,
--lib, and --bin flags from rustc, adding the following flags:
* --emit=[asm,ir,bc,obj,link]
* --crate-type=[dylib,rlib,staticlib,bin,lib]
The -o option has also been redefined to be used for *all* flavors of outputs.
This means that we no longer ignore it for libraries. The --out-dir remains the
same as before.
The new logic for files that rustc emits is as follows:
1. Output types are dictated by the --emit flag. The default value is
--emit=link, and this option can be passed multiple times and have all
options stacked on one another.
2. Crate types are dictated by the --crate-type flag and the #[crate_type]
attribute. The flags can be passed many times and stack with the crate
attribute.
3. If the -o flag is specified, and only one output type is specified, the
output will be emitted at this location. If more than one output type is
specified, then the filename of -o is ignored, and all output goes in the
directory that -o specifies. The -o option always ignores the --out-dir
option.
4. If the --out-dir flag is specified, all output goes in this directory.
5. If -o and --out-dir are both not present, all output goes in the current
directory of the process.
6. When multiple output types are specified, the filestem of all output is the
same as the name of the CrateId (derived from a crate attribute or from the
filestem of the crate file).
Closes #7791
Closes #11056
Closes #11667
2014-02-03 17:27:54 -06:00
|
|
|
match *crate_type {
|
2014-05-06 06:38:01 -05:00
|
|
|
config::CrateTypeExecutable | config::CrateTypeStaticlib => {}
|
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-03 01:19:29 -06:00
|
|
|
_ => {
|
|
|
|
sess.fatal("lto can only be run for executables and \
|
|
|
|
static library outputs");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// 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.
|
2013-12-25 14:08:04 -06:00
|
|
|
let crates = sess.cstore.get_used_crates(cstore::RequireStatic);
|
2014-09-14 22:27:36 -05:00
|
|
|
for (cnum, path) in crates.into_iter() {
|
2014-01-31 14:17:03 -06:00
|
|
|
let name = sess.cstore.get_crate_data(cnum).name.clone();
|
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-03 01:19:29 -06:00
|
|
|
let path = match path {
|
|
|
|
Some(p) => p,
|
|
|
|
None => {
|
2014-05-16 12:45:16 -05:00
|
|
|
sess.fatal(format!("could not find rlib for: `{}`",
|
|
|
|
name).as_slice());
|
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-03 01:19:29 -06:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2013-12-16 22:58:21 -06:00
|
|
|
let archive = ArchiveRO::open(&path).expect("wanted an rlib");
|
2014-07-15 11:13:58 -05:00
|
|
|
let file = path.filename_str().unwrap();
|
|
|
|
let file = file.slice(3, file.len() - 5); // chop off lib/.rlib
|
|
|
|
debug!("reading {}", file);
|
2014-09-17 18:18:12 -05:00
|
|
|
for i in iter::count(0u, 1) {
|
|
|
|
let bc_encoded = time(sess.time_passes(),
|
|
|
|
format!("check for {}.{}.bytecode.deflate", name, i).as_slice(),
|
|
|
|
(),
|
|
|
|
|_| {
|
|
|
|
archive.read(format!("{}.{}.bytecode.deflate",
|
|
|
|
file, i).as_slice())
|
|
|
|
});
|
|
|
|
let bc_encoded = match bc_encoded {
|
|
|
|
Some(data) => data,
|
|
|
|
None => {
|
|
|
|
if i == 0 {
|
|
|
|
// No bitcode was found at all.
|
|
|
|
sess.fatal(format!("missing compressed bytecode in {}",
|
|
|
|
path.display()).as_slice());
|
|
|
|
}
|
|
|
|
// No more bitcode files to read.
|
|
|
|
break;
|
|
|
|
},
|
|
|
|
};
|
|
|
|
let bc_extractor = if is_versioned_bytecode_format(bc_encoded) {
|
|
|
|
|_| {
|
|
|
|
// Read the version
|
|
|
|
let version = extract_bytecode_format_version(bc_encoded);
|
2014-07-31 08:05:08 -05:00
|
|
|
|
2014-09-17 18:18:12 -05:00
|
|
|
if version == 1 {
|
|
|
|
// The only version existing so far
|
|
|
|
let data_size = extract_compressed_bytecode_size_v1(bc_encoded);
|
2014-09-24 06:41:09 -05:00
|
|
|
let compressed_data = bc_encoded[
|
|
|
|
link::RLIB_BYTECODE_OBJECT_V1_DATA_OFFSET..
|
|
|
|
link::RLIB_BYTECODE_OBJECT_V1_DATA_OFFSET + data_size as uint];
|
2014-07-31 08:05:08 -05:00
|
|
|
|
2014-09-17 18:18:12 -05:00
|
|
|
match flate::inflate_bytes(compressed_data) {
|
|
|
|
Some(inflated) => inflated,
|
|
|
|
None => {
|
|
|
|
sess.fatal(format!("failed to decompress bc of `{}`",
|
|
|
|
name).as_slice())
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
sess.fatal(format!("Unsupported bytecode format version {}",
|
|
|
|
version).as_slice())
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
// 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
|
|
|
|
|_| {
|
|
|
|
match flate::inflate_bytes(bc_encoded) {
|
|
|
|
Some(bc) => bc,
|
2014-07-31 08:05:08 -05:00
|
|
|
None => {
|
|
|
|
sess.fatal(format!("failed to decompress bc of `{}`",
|
|
|
|
name).as_slice())
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2014-09-17 18:18:12 -05:00
|
|
|
};
|
2014-07-31 08:05:08 -05:00
|
|
|
|
2014-09-17 18:18:12 -05:00
|
|
|
let bc_decoded = time(sess.time_passes(),
|
|
|
|
format!("decode {}.{}.bc", file, i).as_slice(),
|
|
|
|
(),
|
|
|
|
bc_extractor);
|
2014-07-31 08:05:08 -05:00
|
|
|
|
2014-09-17 18:18:12 -05:00
|
|
|
let ptr = bc_decoded.as_slice().as_ptr();
|
|
|
|
debug!("linking {}, part {}", name, i);
|
|
|
|
time(sess.time_passes(),
|
|
|
|
format!("ll link {}.{}", name, i).as_slice(),
|
|
|
|
(),
|
|
|
|
|()| unsafe {
|
|
|
|
if !llvm::LLVMRustLinkInExternalBitcode(llmod,
|
|
|
|
ptr as *const libc::c_char,
|
|
|
|
bc_decoded.len() as libc::size_t) {
|
|
|
|
write::llvm_err(sess.diagnostic().handler(),
|
|
|
|
format!("failed to load bc of `{}`",
|
|
|
|
name.as_slice()));
|
|
|
|
}
|
|
|
|
});
|
|
|
|
}
|
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-03 01:19:29 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
// Internalize everything but the reachable symbols of the current module
|
2014-05-09 20:45:36 -05:00
|
|
|
let cstrs: Vec<::std::c_str::CString> =
|
|
|
|
reachable.iter().map(|s| s.as_slice().to_c_str()).collect();
|
2014-06-14 07:50:07 -05:00
|
|
|
let arr: Vec<*const i8> = cstrs.iter().map(|c| c.as_ptr()).collect();
|
2013-12-15 06:35:12 -06: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-03 01:19:29 -06:00
|
|
|
unsafe {
|
2014-06-25 14:47:34 -05: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-03 01:19:29 -06:00
|
|
|
arr.len() as libc::size_t);
|
|
|
|
}
|
|
|
|
|
2013-12-11 01:27:15 -06:00
|
|
|
if sess.no_landing_pads() {
|
|
|
|
unsafe {
|
|
|
|
llvm::LLVMRustMarkAllFunctionsNounwind(llmod);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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-03 01:19:29 -06: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);
|
|
|
|
"verify".with_c_str(|s| llvm::LLVMRustAddPass(pm, s));
|
|
|
|
|
|
|
|
let builder = llvm::LLVMPassManagerBuilderCreate();
|
|
|
|
llvm::LLVMPassManagerBuilderPopulateLTOPassManager(builder, pm,
|
|
|
|
/* Internalize = */ False,
|
|
|
|
/* RunInliner = */ True);
|
|
|
|
llvm::LLVMPassManagerBuilderDispose(builder);
|
|
|
|
|
|
|
|
"verify".with_c_str(|s| llvm::LLVMRustAddPass(pm, s));
|
|
|
|
|
2014-09-02 00:35:58 -05: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-03 01:19:29 -06:00
|
|
|
llvm::LLVMRunPassManager(pm, llmod));
|
|
|
|
|
|
|
|
llvm::LLVMDisposePassManager(pm);
|
|
|
|
}
|
|
|
|
debug!("lto done");
|
|
|
|
}
|
2014-07-31 08:05:08 -05: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 &&
|
2014-09-24 06:41:09 -05:00
|
|
|
bc[..magic_id_byte_count] == link::RLIB_BYTECODE_OBJECT_MAGIC;
|
2014-07-31 08:05:08 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
fn extract_bytecode_format_version(bc: &[u8]) -> u32 {
|
|
|
|
return read_from_le_bytes::<u32>(bc, link::RLIB_BYTECODE_OBJECT_VERSION_OFFSET);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn extract_compressed_bytecode_size_v1(bc: &[u8]) -> u64 {
|
|
|
|
return read_from_le_bytes::<u64>(bc, link::RLIB_BYTECODE_OBJECT_V1_DATASIZE_OFFSET);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn read_from_le_bytes<T: Int>(bytes: &[u8], position_in_bytes: uint) -> T {
|
2014-09-24 06:41:09 -05:00
|
|
|
let byte_data = bytes[position_in_bytes..
|
|
|
|
position_in_bytes + mem::size_of::<T>()];
|
2014-07-31 08:05:08 -05:00
|
|
|
let data = unsafe {
|
|
|
|
*(byte_data.as_ptr() as *const T)
|
|
|
|
};
|
|
|
|
|
|
|
|
Int::from_le(data)
|
|
|
|
}
|
|
|
|
|