mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
20f4c45bad
rust/src/rustllvm/PassWrapper.cpp

279 lines
9.1 KiB
C++
Raw Normal View History

Refactor optimization pass handling. Refactor the optimization passes to explicitly use the passes. This commit just re-implements the same passes as were already being run. It also adds an option (behind `-Z`) to run the LLVM lint pass on the unoptimized IR.
2013-05-27 18:15:31 -05: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.
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
#include <stdio.h>
Refactor optimization pass handling. Refactor the optimization passes to explicitly use the passes. This commit just re-implements the same passes as were already being run. It also adds an option (behind `-Z`) to run the LLVM lint pass on the unoptimized IR.
2013-05-27 18:15:31 -05:00
#include "rustllvm.h"
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
#include "llvm/Support/CBindingWrapping.h"
Update to LLVM head and mark various ptrs as nonnull.
2014-05-20 16:42:20 -05:00
#include "llvm/Support/FileSystem.h"
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
#include "llvm/Target/TargetLibraryInfo.h"
#include "llvm/Transforms/IPO/PassManagerBuilder.h"
Refactor optimization pass handling. Refactor the optimization passes to explicitly use the passes. This commit just re-implements the same passes as were already being run. It also adds an option (behind `-Z`) to run the LLVM lint pass on the unoptimized IR.
2013-05-27 18:15:31 -05:00
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
#include "llvm-c/Transforms/PassManagerBuilder.h"
Refactor optimization pass handling. Refactor the optimization passes to explicitly use the passes. This commit just re-implements the same passes as were already being run. It also adds an option (behind `-Z`) to run the LLVM lint pass on the unoptimized IR.
2013-05-27 18:15:31 -05:00
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
using namespace llvm;
Refactor optimization pass handling. Refactor the optimization passes to explicitly use the passes. This commit just re-implements the same passes as were already being run. It also adds an option (behind `-Z`) to run the LLVM lint pass on the unoptimized IR.
2013-05-27 18:15:31 -05:00
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
extern cl::opt<bool> EnableARMEHABI;
Refactor optimization pass handling. Refactor the optimization passes to explicitly use the passes. This commit just re-implements the same passes as were already being run. It also adds an option (behind `-Z`) to run the LLVM lint pass on the unoptimized IR.
2013-05-27 18:15:31 -05:00
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
typedef struct LLVMOpaquePass *LLVMPassRef;
typedef struct LLVMOpaqueTargetMachine *LLVMTargetMachineRef;
DEFINE_STDCXX_CONVERSION_FUNCTIONS(Pass, LLVMPassRef)
DEFINE_STDCXX_CONVERSION_FUNCTIONS(TargetMachine, LLVMTargetMachineRef)
DEFINE_STDCXX_CONVERSION_FUNCTIONS(PassManagerBuilder, LLVMPassManagerBuilderRef)
Refactor optimization pass handling. Refactor the optimization passes to explicitly use the passes. This commit just re-implements the same passes as were already being run. It also adds an option (behind `-Z`) to run the LLVM lint pass on the unoptimized IR.
2013-05-27 18:15:31 -05:00
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
extern "C" void
LLVMInitializePasses() {
Further refactor optimization pass handling This refactors pass handling to use the argument names, so it can be used in a similar manner to `opt`. This may be slightly less efficient than the previous version, but it is much easier to maintain. It also adds in the ability to specify a custom pipeline on the command line, this overrides the normal passes, however. This should completely close #2396.
2013-05-29 03:08:20 -05:00
PassRegistry &Registry = *PassRegistry::getPassRegistry();
initializeCore(Registry);
initializeCodeGen(Registry);
initializeScalarOpts(Registry);
initializeVectorization(Registry);
initializeIPO(Registry);
initializeAnalysis(Registry);
initializeIPA(Registry);
initializeTransformUtils(Registry);
initializeInstCombine(Registry);
initializeInstrumentation(Registry);
initializeTarget(Registry);
}
Refactor optimization pass handling. Refactor the optimization passes to explicitly use the passes. This commit just re-implements the same passes as were already being run. It also adds an option (behind `-Z`) to run the LLVM lint pass on the unoptimized IR.
2013-05-27 18:15:31 -05:00
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
extern "C" bool
LLVMRustAddPass(LLVMPassManagerRef PM, const char *PassName) {
PassManagerBase *pm = unwrap(PM);
Refactor optimization pass handling. Refactor the optimization passes to explicitly use the passes. This commit just re-implements the same passes as were already being run. It also adds an option (behind `-Z`) to run the LLVM lint pass on the unoptimized IR.
2013-05-27 18:15:31 -05:00
Further refactor optimization pass handling This refactors pass handling to use the argument names, so it can be used in a similar manner to `opt`. This may be slightly less efficient than the previous version, but it is much easier to maintain. It also adds in the ability to specify a custom pipeline on the command line, this overrides the normal passes, however. This should completely close #2396.
2013-05-29 03:08:20 -05:00
StringRef SR(PassName);
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
PassRegistry *PR = PassRegistry::getPassRegistry();
Refactor optimization pass handling. Refactor the optimization passes to explicitly use the passes. This commit just re-implements the same passes as were already being run. It also adds an option (behind `-Z`) to run the LLVM lint pass on the unoptimized IR.
2013-05-27 18:15:31 -05:00
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
const PassInfo *PI = PR->getPassInfo(SR);
Further refactor optimization pass handling This refactors pass handling to use the argument names, so it can be used in a similar manner to `opt`. This may be slightly less efficient than the previous version, but it is much easier to maintain. It also adds in the ability to specify a custom pipeline on the command line, this overrides the normal passes, however. This should completely close #2396.
2013-05-29 03:08:20 -05:00
if (PI) {
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
pm->add(PI->createPass());
return true;
}
return false;
}
extern "C" LLVMTargetMachineRef
LLVMRustCreateTargetMachine(const char *triple,
const char *cpu,
const char *feature,
CodeModel::Model CM,
Reloc::Model RM,
CodeGenOpt::Level OptLevel,
add -Z soft-float option This change adds -Z soft-float option for generating software floating point library calls. It also implies using soft float ABI, that is the same as llc. It is useful for targets that have no FPU.
2013-09-30 00:20:52 -05:00
bool EnableSegmentedStacks,
enable fp-elim when debug info is disabled This can almost be fully disabled, as it no longer breaks retrieving a backtrace on OS X as verified by @alexcrichton. However, it still breaks retrieving the values of parameters. This should be fixable in the future via a proper location list... Closes #7477
2014-01-28 13:59:28 -06:00
bool UseSoftFloat,
rustc: Enable -f{function,data}-sections The compiler has previously been producing binaries on the order of 1.8MB for hello world programs "fn main() {}". This is largely a result of the compilation model used by compiling entire libraries into a single object file and because static linking is favored by default. When linking, linkers will pull in the entire contents of an object file if any symbol from the object file is used. This means that if any symbol from a rust library is used, the entire library is pulled in unconditionally, regardless of whether the library is used or not. Traditional C/C++ projects do not normally encounter these large executable problems because their archives (rust's rlibs) are composed of many objects. Because of this, linkers can eliminate entire objects from being in the final executable. With rustc, however, the linker does not have the opportunity to leave out entire object files. In order to get similar benefits from dead code stripping at link time, this commit enables the -ffunction-sections and -fdata-sections flags in LLVM, as well as passing --gc-sections to the linker *by default*. This means that each function and each global will be placed into its own section, allowing the linker to GC all unused functions and data symbols. By enabling these flags, rust is able to generate much smaller binaries default. On linux, a hello world binary went from 1.8MB to 597K (a 67% reduction in size). The output size of dynamic libraries remained constant, but the output size of rlibs increased, as seen below: libarena - 2.27% bigger ( 292872 => 299508) libcollections - 0.64% bigger ( 6765884 => 6809076) libflate - 0.83% bigger ( 186516 => 188060) libfourcc - 14.71% bigger ( 307290 => 352498) libgetopts - 4.42% bigger ( 761468 => 795102) libglob - 2.73% bigger ( 899932 => 924542) libgreen - 9.63% bigger ( 1281718 => 1405124) libhexfloat - 13.88% bigger ( 333738 => 380060) liblibc - 10.79% bigger ( 551280 => 610736) liblog - 10.93% bigger ( 218208 => 242060) libnative - 8.26% bigger ( 1362096 => 1474658) libnum - 2.34% bigger ( 2583400 => 2643916) librand - 1.72% bigger ( 1608684 => 1636394) libregex - 6.50% bigger ( 1747768 => 1861398) librustc - 4.21% bigger (151820192 => 158218924) librustdoc - 8.96% bigger ( 13142604 => 14320544) librustuv - 4.13% bigger ( 4366896 => 4547304) libsemver - 2.66% bigger ( 396166 => 406686) libserialize - 1.91% bigger ( 6878396 => 7009822) libstd - 3.59% bigger ( 39485286 => 40902218) libsync - 3.95% bigger ( 1386390 => 1441204) libsyntax - 4.96% bigger ( 35757202 => 37530798) libterm - 13.99% bigger ( 924580 => 1053902) libtest - 6.04% bigger ( 2455720 => 2604092) libtime - 2.84% bigger ( 1075708 => 1106242) liburl - 6.53% bigger ( 590458 => 629004) libuuid - 4.63% bigger ( 326350 => 341466) libworkcache - 8.45% bigger ( 1230702 => 1334750) This increase in size is a result of encoding many more section names into each object file (rlib). These increases are moderate enough that this change seems worthwhile to me, due to the drastic improvements seen in the final artifacts. The overall increase of the stage2 target folder (not the size of an install) went from 337MB to 348MB (3% increase). Additionally, linking is generally slower when executed with all these new sections plus the --gc-sections flag. The stage0 compiler takes 1.4s to link the `rustc` binary, where the stage1 compiler takes 1.9s to link the binary. Three megabytes are shaved off the binary. I found this increase in link time to be acceptable relative to the benefits of code size gained. This commit only enables --gc-sections for *executables*, not dynamic libraries. LLVM does all the heavy lifting when producing an object file for a dynamic library, so there is little else for the linker to do (remember that we only have one object file). I conducted similar experiments by putting a *module's* functions and data symbols into its own section (granularity moved to a module level instead of a function/static level). The size benefits of a hello world were seen to be on the order of 400K rather than 1.2MB. It seemed that enough benefit was gained using ffunction-sections that this route was less desirable, despite the lesser increases in binary rlib size.
2014-04-28 19:17:18 -05:00
bool NoFramePointerElim,
bool FunctionSections,
bool DataSections) {
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
std::string Error;
Triple Trip(Triple::normalize(triple));
const llvm::Target *TheTarget = TargetRegistry::lookupTarget(Trip.getTriple(),
Error);
if (TheTarget == NULL) {
rustc: Fix passing errors from LLVM to rustc Many of the instances of setting a global error variable ended up leaving a dangling pointer into free'd memory. This changes the method of error transmission to strdup any error and "relinquish ownership" to rustc when it gets an error. The corresponding Rust code will then free the error as necessary. Closes #12865
2014-04-15 09:25:22 -05:00
LLVMRustSetLastError(Error.c_str());
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
return NULL;
}
TargetOptions Options;
enable fp-elim when debug info is disabled This can almost be fully disabled, as it no longer breaks retrieving a backtrace on OS X as verified by @alexcrichton. However, it still breaks retrieving the values of parameters. This should be fixable in the future via a proper location list... Closes #7477
2014-01-28 13:59:28 -06:00
Options.NoFramePointerElim = NoFramePointerElim;
Upgrade LLVM This comes with a number of fixes to be compatible with upstream LLVM: * Previously all monomorphizations of "mem::size_of()" would receive the same symbol. In the past LLVM would silently rename duplicated symbols, but it appears to now be dropping the duplicate symbols and functions now. The symbol names of monomorphized functions are now no longer solely based on the type of the function, but rather the type and the unique hash for the monomorphization. * Split stacks are no longer a global feature controlled by a flag in LLVM. Instead, they are opt-in on a per-function basis through a function attribute. The rust #[no_split_stack] attribute will disable this, otherwise all functions have #[split_stack] attached to them. * The compare and swap instruction now takes two atomic orderings, one for the successful case and one for the failure case. LLVM internally has an implementation of calculating the appropriate failure ordering given a particular success ordering (previously only a success ordering was specified), and I copied that into the intrinsic translation so the failure ordering isn't supplied on a source level for now. * Minor tweaks to LLVM's API in terms of debuginfo, naming, c++11 conventions, etc.
2014-03-31 16:43:19 -05:00
#if LLVM_VERSION_MINOR < 5
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
Options.EnableSegmentedStacks = EnableSegmentedStacks;
Upgrade LLVM This comes with a number of fixes to be compatible with upstream LLVM: * Previously all monomorphizations of "mem::size_of()" would receive the same symbol. In the past LLVM would silently rename duplicated symbols, but it appears to now be dropping the duplicate symbols and functions now. The symbol names of monomorphized functions are now no longer solely based on the type of the function, but rather the type and the unique hash for the monomorphization. * Split stacks are no longer a global feature controlled by a flag in LLVM. Instead, they are opt-in on a per-function basis through a function attribute. The rust #[no_split_stack] attribute will disable this, otherwise all functions have #[split_stack] attached to them. * The compare and swap instruction now takes two atomic orderings, one for the successful case and one for the failure case. LLVM internally has an implementation of calculating the appropriate failure ordering given a particular success ordering (previously only a success ordering was specified), and I copied that into the intrinsic translation so the failure ordering isn't supplied on a source level for now. * Minor tweaks to LLVM's API in terms of debuginfo, naming, c++11 conventions, etc.
2014-03-31 16:43:19 -05:00
#endif
Update llvm.
2013-12-27 14:31:49 -06:00
Options.FloatABIType = FloatABI::Default;
add -Z soft-float option This change adds -Z soft-float option for generating software floating point library calls. It also implies using soft float ABI, that is the same as llc. It is useful for targets that have no FPU.
2013-09-30 00:20:52 -05:00
Options.UseSoftFloat = UseSoftFloat;
if (UseSoftFloat) {
Options.FloatABIType = FloatABI::Soft;
}
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
TargetMachine *TM = TheTarget->createTargetMachine(Trip.getTriple(),
cpu,
feature,
Options,
RM,
CM,
OptLevel);
rustc: Enable -f{function,data}-sections The compiler has previously been producing binaries on the order of 1.8MB for hello world programs "fn main() {}". This is largely a result of the compilation model used by compiling entire libraries into a single object file and because static linking is favored by default. When linking, linkers will pull in the entire contents of an object file if any symbol from the object file is used. This means that if any symbol from a rust library is used, the entire library is pulled in unconditionally, regardless of whether the library is used or not. Traditional C/C++ projects do not normally encounter these large executable problems because their archives (rust's rlibs) are composed of many objects. Because of this, linkers can eliminate entire objects from being in the final executable. With rustc, however, the linker does not have the opportunity to leave out entire object files. In order to get similar benefits from dead code stripping at link time, this commit enables the -ffunction-sections and -fdata-sections flags in LLVM, as well as passing --gc-sections to the linker *by default*. This means that each function and each global will be placed into its own section, allowing the linker to GC all unused functions and data symbols. By enabling these flags, rust is able to generate much smaller binaries default. On linux, a hello world binary went from 1.8MB to 597K (a 67% reduction in size). The output size of dynamic libraries remained constant, but the output size of rlibs increased, as seen below: libarena - 2.27% bigger ( 292872 => 299508) libcollections - 0.64% bigger ( 6765884 => 6809076) libflate - 0.83% bigger ( 186516 => 188060) libfourcc - 14.71% bigger ( 307290 => 352498) libgetopts - 4.42% bigger ( 761468 => 795102) libglob - 2.73% bigger ( 899932 => 924542) libgreen - 9.63% bigger ( 1281718 => 1405124) libhexfloat - 13.88% bigger ( 333738 => 380060) liblibc - 10.79% bigger ( 551280 => 610736) liblog - 10.93% bigger ( 218208 => 242060) libnative - 8.26% bigger ( 1362096 => 1474658) libnum - 2.34% bigger ( 2583400 => 2643916) librand - 1.72% bigger ( 1608684 => 1636394) libregex - 6.50% bigger ( 1747768 => 1861398) librustc - 4.21% bigger (151820192 => 158218924) librustdoc - 8.96% bigger ( 13142604 => 14320544) librustuv - 4.13% bigger ( 4366896 => 4547304) libsemver - 2.66% bigger ( 396166 => 406686) libserialize - 1.91% bigger ( 6878396 => 7009822) libstd - 3.59% bigger ( 39485286 => 40902218) libsync - 3.95% bigger ( 1386390 => 1441204) libsyntax - 4.96% bigger ( 35757202 => 37530798) libterm - 13.99% bigger ( 924580 => 1053902) libtest - 6.04% bigger ( 2455720 => 2604092) libtime - 2.84% bigger ( 1075708 => 1106242) liburl - 6.53% bigger ( 590458 => 629004) libuuid - 4.63% bigger ( 326350 => 341466) libworkcache - 8.45% bigger ( 1230702 => 1334750) This increase in size is a result of encoding many more section names into each object file (rlib). These increases are moderate enough that this change seems worthwhile to me, due to the drastic improvements seen in the final artifacts. The overall increase of the stage2 target folder (not the size of an install) went from 337MB to 348MB (3% increase). Additionally, linking is generally slower when executed with all these new sections plus the --gc-sections flag. The stage0 compiler takes 1.4s to link the `rustc` binary, where the stage1 compiler takes 1.9s to link the binary. Three megabytes are shaved off the binary. I found this increase in link time to be acceptable relative to the benefits of code size gained. This commit only enables --gc-sections for *executables*, not dynamic libraries. LLVM does all the heavy lifting when producing an object file for a dynamic library, so there is little else for the linker to do (remember that we only have one object file). I conducted similar experiments by putting a *module's* functions and data symbols into its own section (granularity moved to a module level instead of a function/static level). The size benefits of a hello world were seen to be on the order of 400K rather than 1.2MB. It seemed that enough benefit was gained using ffunction-sections that this route was less desirable, despite the lesser increases in binary rlib size.
2014-04-28 19:17:18 -05:00
TM->setDataSections(DataSections);
TM->setFunctionSections(FunctionSections);
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
return wrap(TM);
}
extern "C" void
LLVMRustDisposeTargetMachine(LLVMTargetMachineRef TM) {
delete unwrap(TM);
}
// Unfortunately, LLVM doesn't expose a C API to add the corresponding analysis
// passes for a target to a pass manager. We export that functionality through
// this function.
extern "C" void
LLVMRustAddAnalysisPasses(LLVMTargetMachineRef TM,
LLVMPassManagerRef PMR,
LLVMModuleRef M) {
PassManagerBase *PM = unwrap(PMR);
Upgrade LLVM This comes with a number of fixes to be compatible with upstream LLVM: * Previously all monomorphizations of "mem::size_of()" would receive the same symbol. In the past LLVM would silently rename duplicated symbols, but it appears to now be dropping the duplicate symbols and functions now. The symbol names of monomorphized functions are now no longer solely based on the type of the function, but rather the type and the unique hash for the monomorphization. * Split stacks are no longer a global feature controlled by a flag in LLVM. Instead, they are opt-in on a per-function basis through a function attribute. The rust #[no_split_stack] attribute will disable this, otherwise all functions have #[split_stack] attached to them. * The compare and swap instruction now takes two atomic orderings, one for the successful case and one for the failure case. LLVM internally has an implementation of calculating the appropriate failure ordering given a particular success ordering (previously only a success ordering was specified), and I copied that into the intrinsic translation so the failure ordering isn't supplied on a source level for now. * Minor tweaks to LLVM's API in terms of debuginfo, naming, c++11 conventions, etc.
2014-03-31 16:43:19 -05:00
#if LLVM_VERSION_MINOR >= 5
PM->add(new DataLayoutPass(unwrap(M)));
#else
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
PM->add(new DataLayout(unwrap(M)));
Upgrade LLVM This comes with a number of fixes to be compatible with upstream LLVM: * Previously all monomorphizations of "mem::size_of()" would receive the same symbol. In the past LLVM would silently rename duplicated symbols, but it appears to now be dropping the duplicate symbols and functions now. The symbol names of monomorphized functions are now no longer solely based on the type of the function, but rather the type and the unique hash for the monomorphization. * Split stacks are no longer a global feature controlled by a flag in LLVM. Instead, they are opt-in on a per-function basis through a function attribute. The rust #[no_split_stack] attribute will disable this, otherwise all functions have #[split_stack] attached to them. * The compare and swap instruction now takes two atomic orderings, one for the successful case and one for the failure case. LLVM internally has an implementation of calculating the appropriate failure ordering given a particular success ordering (previously only a success ordering was specified), and I copied that into the intrinsic translation so the failure ordering isn't supplied on a source level for now. * Minor tweaks to LLVM's API in terms of debuginfo, naming, c++11 conventions, etc.
2014-03-31 16:43:19 -05:00
#endif
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
unwrap(TM)->addAnalysisPasses(*PM);
}
// Unfortunately, the LLVM C API doesn't provide a way to set the `LibraryInfo`
// field of a PassManagerBuilder, we expose our own method of doing so.
extern "C" void
Add a crate for missing stubs from libcore The core library in theory has 0 dependencies, but in practice it has some in order for it to be efficient. These dependencies are in the form of the basic memory operations provided by libc traditionally, such as memset, memcmp, etc. These functions are trivial to implement and themselves have 0 dependencies. This commit adds a new crate, librlibc, which will serve the purpose of providing these dependencies. The crate is never linked to by default, but is available to be linked to by downstream consumers. Normally these functions are provided by the system libc, but in other freestanding contexts a libc may not be available. In these cases, librlibc will suffice for enabling execution with libcore. cc #10116
2014-05-14 13:24:12 -05:00
LLVMRustAddBuilderLibraryInfo(LLVMPassManagerBuilderRef PMB,
LLVMModuleRef M,
bool DisableSimplifyLibCalls) {
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
Triple TargetTriple(unwrap(M)->getTargetTriple());
Add a crate for missing stubs from libcore The core library in theory has 0 dependencies, but in practice it has some in order for it to be efficient. These dependencies are in the form of the basic memory operations provided by libc traditionally, such as memset, memcmp, etc. These functions are trivial to implement and themselves have 0 dependencies. This commit adds a new crate, librlibc, which will serve the purpose of providing these dependencies. The crate is never linked to by default, but is available to be linked to by downstream consumers. Normally these functions are provided by the system libc, but in other freestanding contexts a libc may not be available. In these cases, librlibc will suffice for enabling execution with libcore. cc #10116
2014-05-14 13:24:12 -05:00
TargetLibraryInfo *TLI = new TargetLibraryInfo(TargetTriple);
if (DisableSimplifyLibCalls)
TLI->disableAllFunctions();
unwrap(PMB)->LibraryInfo = TLI;
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
}
// Unfortunately, the LLVM C API doesn't provide a way to create the
// TargetLibraryInfo pass, so we use this method to do so.
extern "C" void
Add a crate for missing stubs from libcore The core library in theory has 0 dependencies, but in practice it has some in order for it to be efficient. These dependencies are in the form of the basic memory operations provided by libc traditionally, such as memset, memcmp, etc. These functions are trivial to implement and themselves have 0 dependencies. This commit adds a new crate, librlibc, which will serve the purpose of providing these dependencies. The crate is never linked to by default, but is available to be linked to by downstream consumers. Normally these functions are provided by the system libc, but in other freestanding contexts a libc may not be available. In these cases, librlibc will suffice for enabling execution with libcore. cc #10116
2014-05-14 13:24:12 -05:00
LLVMRustAddLibraryInfo(LLVMPassManagerRef PMB,
LLVMModuleRef M,
bool DisableSimplifyLibCalls) {
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
Triple TargetTriple(unwrap(M)->getTargetTriple());
Add a crate for missing stubs from libcore The core library in theory has 0 dependencies, but in practice it has some in order for it to be efficient. These dependencies are in the form of the basic memory operations provided by libc traditionally, such as memset, memcmp, etc. These functions are trivial to implement and themselves have 0 dependencies. This commit adds a new crate, librlibc, which will serve the purpose of providing these dependencies. The crate is never linked to by default, but is available to be linked to by downstream consumers. Normally these functions are provided by the system libc, but in other freestanding contexts a libc may not be available. In these cases, librlibc will suffice for enabling execution with libcore. cc #10116
2014-05-14 13:24:12 -05:00
TargetLibraryInfo *TLI = new TargetLibraryInfo(TargetTriple);
if (DisableSimplifyLibCalls)
TLI->disableAllFunctions();
unwrap(PMB)->add(TLI);
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
}
// Unfortunately, the LLVM C API doesn't provide an easy way of iterating over
// all the functions in a module, so we do that manually here. You'll find
// similar code in clang's BackendUtil.cpp file.
extern "C" void
LLVMRustRunFunctionPassManager(LLVMPassManagerRef PM, LLVMModuleRef M) {
FunctionPassManager *P = unwrap<FunctionPassManager>(PM);
P->doInitialization();
for (Module::iterator I = unwrap(M)->begin(),
E = unwrap(M)->end(); I != E; ++I)
if (!I->isDeclaration())
P->run(*I);
P->doFinalization();
}
extern "C" void
Tweak pass management and add some more options The only changes to the default passes is that O1 now doesn't run the inline pass, just always-inline with lifetime intrinsics. O2 also now has a threshold of 225 instead of 275. Otherwise the default passes being run is the same. I've also added a few more options for configuring the pass pipeline. Namely you can now specify arguments to LLVM directly via the `--llvm-args` command line option which operates similarly to `--passes`. I also added the ability to turn off pre-population of the pass manager in case you want to run *only* your own passes.
2013-08-30 19:56:04 -05:00
LLVMRustSetLLVMOptions(int Argc, char **Argv) {
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
// Initializing the command-line options more than once is not allowed. So,
// check if they've already been initialized. (This could happen if we're
// being called from rustpkg, for example). If the arguments change, then
// that's just kinda unfortunate.
static bool initialized = false;
if (initialized) return;
initialized = true;
Tweak pass management and add some more options The only changes to the default passes is that O1 now doesn't run the inline pass, just always-inline with lifetime intrinsics. O2 also now has a threshold of 225 instead of 275. Otherwise the default passes being run is the same. I've also added a few more options for configuring the pass pipeline. Namely you can now specify arguments to LLVM directly via the `--llvm-args` command line option which operates similarly to `--passes`. I also added the ability to turn off pre-population of the pass manager in case you want to run *only* your own passes.
2013-08-30 19:56:04 -05:00
cl::ParseCommandLineOptions(Argc, Argv);
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
}
extern "C" bool
LLVMRustWriteOutputFile(LLVMTargetMachineRef Target,
LLVMPassManagerRef PMR,
LLVMModuleRef M,
const char *path,
TargetMachine::CodeGenFileType FileType) {
PassManager *PM = unwrap<PassManager>(PMR);
std::string ErrorInfo;
rustc: Get rustc compiling with LLVM 3.{3,4} again The travis builds have been breaking recently because LLVM 3.5 upstream is changing. This looks like it's likely to continue, so it would be more useful for us if we could lock ourselves to a system LLVM version that is not changing. This commit has the support to bring our C++ glue to LLVM back in line with what was possible back in LLVM 3.{3,4}. I don't think we're going to be able to reasonably protect against regressions in the future, but this kind of code is a good sign that we can continue to use the system LLVM for simple-ish things. Codegen for ARM won't work and it won't have some of the perf improvements we have, but using the system LLVM should work well enough for development.
2014-02-26 16:06:27 -06:00
#if LLVM_VERSION_MINOR >= 4
Update LLVM Upstream LLVM has changed slightly such that our PassWrapper.cpp no longer comiles (travis errors). This updates the bundled LLVM to the latest nightly which will hopefully fix the travis errors we're seeing.
2014-02-25 11:26:11 -06:00
raw_fd_ostream OS(path, ErrorInfo, sys::fs::F_None);
rustc: Get rustc compiling with LLVM 3.{3,4} again The travis builds have been breaking recently because LLVM 3.5 upstream is changing. This looks like it's likely to continue, so it would be more useful for us if we could lock ourselves to a system LLVM version that is not changing. This commit has the support to bring our C++ glue to LLVM back in line with what was possible back in LLVM 3.{3,4}. I don't think we're going to be able to reasonably protect against regressions in the future, but this kind of code is a good sign that we can continue to use the system LLVM for simple-ish things. Codegen for ARM won't work and it won't have some of the perf improvements we have, but using the system LLVM should work well enough for development.
2014-02-26 16:06:27 -06:00
#else
raw_fd_ostream OS(path, ErrorInfo, raw_fd_ostream::F_Binary);
#endif
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
if (ErrorInfo != "") {
rustc: Fix passing errors from LLVM to rustc Many of the instances of setting a global error variable ended up leaving a dangling pointer into free'd memory. This changes the method of error transmission to strdup any error and "relinquish ownership" to rustc when it gets an error. The corresponding Rust code will then free the error as necessary. Closes #12865
2014-04-15 09:25:22 -05:00
LLVMRustSetLastError(ErrorInfo.c_str());
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
return false;
}
formatted_raw_ostream FOS(OS);
unwrap(Target)->addPassesToEmitFile(*PM, FOS, FileType, false);
PM->run(*unwrap(M));
return true;
}
extern "C" void
LLVMRustPrintModule(LLVMPassManagerRef PMR,
LLVMModuleRef M,
const char* path) {
PassManager *PM = unwrap<PassManager>(PMR);
std::string ErrorInfo;
rustc: Get rustc compiling with LLVM 3.{3,4} again The travis builds have been breaking recently because LLVM 3.5 upstream is changing. This looks like it's likely to continue, so it would be more useful for us if we could lock ourselves to a system LLVM version that is not changing. This commit has the support to bring our C++ glue to LLVM back in line with what was possible back in LLVM 3.{3,4}. I don't think we're going to be able to reasonably protect against regressions in the future, but this kind of code is a good sign that we can continue to use the system LLVM for simple-ish things. Codegen for ARM won't work and it won't have some of the perf improvements we have, but using the system LLVM should work well enough for development.
2014-02-26 16:06:27 -06:00
#if LLVM_VERSION_MINOR >= 4
Update LLVM Upstream LLVM has changed slightly such that our PassWrapper.cpp no longer comiles (travis errors). This updates the bundled LLVM to the latest nightly which will hopefully fix the travis errors we're seeing.
2014-02-25 11:26:11 -06:00
raw_fd_ostream OS(path, ErrorInfo, sys::fs::F_None);
rustc: Get rustc compiling with LLVM 3.{3,4} again The travis builds have been breaking recently because LLVM 3.5 upstream is changing. This looks like it's likely to continue, so it would be more useful for us if we could lock ourselves to a system LLVM version that is not changing. This commit has the support to bring our C++ glue to LLVM back in line with what was possible back in LLVM 3.{3,4}. I don't think we're going to be able to reasonably protect against regressions in the future, but this kind of code is a good sign that we can continue to use the system LLVM for simple-ish things. Codegen for ARM won't work and it won't have some of the perf improvements we have, but using the system LLVM should work well enough for development.
2014-02-26 16:06:27 -06:00
#else
raw_fd_ostream OS(path, ErrorInfo, raw_fd_ostream::F_Binary);
#endif
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
formatted_raw_ostream FOS(OS);
rustc: Get rustc compiling with LLVM 3.{3,4} again The travis builds have been breaking recently because LLVM 3.5 upstream is changing. This looks like it's likely to continue, so it would be more useful for us if we could lock ourselves to a system LLVM version that is not changing. This commit has the support to bring our C++ glue to LLVM back in line with what was possible back in LLVM 3.{3,4}. I don't think we're going to be able to reasonably protect against regressions in the future, but this kind of code is a good sign that we can continue to use the system LLVM for simple-ish things. Codegen for ARM won't work and it won't have some of the perf improvements we have, but using the system LLVM should work well enough for development.
2014-02-26 16:06:27 -06:00
#if LLVM_VERSION_MINOR >= 5
Upgrade LLVM This upgrade brings commit by @eddyb to help optimizations of virtual calls in a few places (https://github.com/llvm-mirror/llvm/commit/6d2bd95) as well as a commit by @c-a to *greatly* improve the runtime of the optimization passes (https://github.com/rust-lang/llvm/pull/3). Nice work to these guys!
2014-01-27 14:45:48 -06:00
PM->add(createPrintModulePass(FOS));
rustc: Get rustc compiling with LLVM 3.{3,4} again The travis builds have been breaking recently because LLVM 3.5 upstream is changing. This looks like it's likely to continue, so it would be more useful for us if we could lock ourselves to a system LLVM version that is not changing. This commit has the support to bring our C++ glue to LLVM back in line with what was possible back in LLVM 3.{3,4}. I don't think we're going to be able to reasonably protect against regressions in the future, but this kind of code is a good sign that we can continue to use the system LLVM for simple-ish things. Codegen for ARM won't work and it won't have some of the perf improvements we have, but using the system LLVM should work well enough for development.
2014-02-26 16:06:27 -06:00
#else
PM->add(createPrintModulePass(&FOS));
#endif
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
PM->run(*unwrap(M));
}
extern "C" void
LLVMRustPrintPasses() {
LLVMInitializePasses();
struct MyListener : PassRegistrationListener {
void passEnumerate(const PassInfo *info) {
if (info->getPassArgument() && *info->getPassArgument()) {
printf("%15s - %s\n", info->getPassArgument(),
info->getPassName());
}
}
} listener;
PassRegistry *PR = PassRegistry::getPassRegistry();
PR->enumerateWith(&listener);
Refactor optimization pass handling. Refactor the optimization passes to explicitly use the passes. This commit just re-implements the same passes as were already being run. It also adds an option (behind `-Z`) to run the LLVM lint pass on the unoptimized IR.
2013-05-27 18:15:31 -05:00
}
rustc: Dispose of LLVM passes in test cases
2013-06-19 17:18:25 -05:00
Rewrite pass management with LLVM Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
2013-08-22 22:58:42 -05:00
extern "C" void
LLVMRustAddAlwaysInlinePass(LLVMPassManagerBuilderRef PMB, bool AddLifetimes) {
unwrap(PMB)->Inliner = createAlwaysInlinerPass(AddLifetimes);
rustc: Dispose of LLVM passes in test cases
2013-06-19 17:18:25 -05: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-03 01:19:29 -06:00
extern "C" void
LLVMRustRunRestrictionPass(LLVMModuleRef M, char **symbols, size_t len) {
PassManager passes;
ArrayRef<const char*> ref(symbols, len);
passes.add(llvm::createInternalizePass(ref));
passes.run(*unwrap(M));
}
Disable all unwinding on -Z no-landing-pads LTO When performing LTO, the rust compiler has an opportunity to completely strip all landing pads in all dependent libraries. I've modified the LTO pass to recognize the -Z no-landing-pads option when also running an LTO pass to flag everything in LLVM as nothrow. I've verified that this prevents any and all invoke instructions from being emitted. I believe that this is one of our best options for moving forward with accomodating use-cases where unwinding doesn't really make sense. This will allow libraries to be built with landing pads by default but allow usage of them in contexts where landing pads aren't necessary. cc #10780
2013-12-11 01:27:15 -06:00
extern "C" void
LLVMRustMarkAllFunctionsNounwind(LLVMModuleRef M) {
for (Module::iterator GV = unwrap(M)->begin(),
E = unwrap(M)->end(); GV != E; ++GV) {
GV->setDoesNotThrow();
Function *F = dyn_cast<Function>(GV);
if (F == NULL)
continue;
for (Function::iterator B = F->begin(), BE = F->end(); B != BE; ++B) {
for (BasicBlock::iterator I = B->begin(), IE = B->end();
I != IE; ++I) {
if (isa<InvokeInst>(I)) {
InvokeInst *CI = cast<InvokeInst>(I);
CI->setDoesNotThrow();
}
}
}
}
}
Reference in New Issue Copy Permalink