- 18 10月, 2017 1 次提交
-
-
由 Alex Crichton 提交于
On MSVC targets rustc will add symbols prefixed with `_imp_` to LLVM modules to "emulate" dllexported statics as that workaround is still in place after #27438 hasn't been solved otherwise. These statics, however, were getting gc'd by ThinLTO accidentally which later would cause linking failures. This commit updates the location we add such symbols to happen just before codegen to ensure that (a) they're not eliminated by the optimizer and (b) the optimizer doesn't even worry about them. Closes #45347
-
- 15 10月, 2017 1 次提交
-
-
由 Alex Crichton 提交于
First the `addPreservedGUID` function forgot to take care of "alias" summaries. I'm not 100% sure what this is but the current code now matches upstream. Next the `computeDeadSymbols` return value wasn't actually being used, but it needed to be used! Together these should... Closes #45195
-
- 10 10月, 2017 1 次提交
-
-
由 Alex Crichton 提交于
Some targets, like msp430 and nvptx, don't work with multiple codegen units right now for bugs or fundamental reasons. To expose this allow targets to express a default. Closes #45000
-
- 09 10月, 2017 1 次提交
-
-
由 Aidan Hobson Sayers 提交于
Fixes #43402 (take 2)
-
- 07 10月, 2017 1 次提交
-
-
由 Alex Crichton 提交于
This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. "Thin" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is, we won't load upstream rlibs, but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode, like full LTO today, we'll optimize all upstream dependencies in "thin" mode. Unlike today, however, this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from, but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy, but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO, as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation, where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!
-
- 06 10月, 2017 1 次提交
-
-
由 Michael Woerister 提交于
-
- 04 10月, 2017 1 次提交
-
-
由 Aidan Hobson Sayers 提交于
Fixes #43402 now there's no multithreaded panic printouts Also update a comment
-
- 02 10月, 2017 1 次提交
-
-
由 Michael Woerister 提交于
-
- 30 9月, 2017 1 次提交
-
-
由 Alex Crichton 提交于
This commit is a refactoring of the LTO backend in Rust to support compilations with multiple codegen units. The immediate result of this PR is to remove the artificial error emitted by rustc about `-C lto -C codegen-units-8`, but longer term this is intended to lay the groundwork for LTO with incremental compilation and ultimately be the underpinning of ThinLTO support. The problem here that needed solving is that when rustc is producing multiple codegen units in one compilation LTO needs to merge them all together. Previously only upstream dependencies were merged and it was inherently relied on that there was only one local codegen unit. Supporting this involved refactoring the optimization backend architecture for rustc, namely splitting the `optimize_and_codegen` function into `optimize` and `codegen`. After an LLVM module has been optimized it may be blocked and queued up for LTO, and only after LTO are modules code generated. Non-LTO compilations should look the same as they do today backend-wise, we'll spin up a thread for each codegen unit and optimize/codegen in that thread. LTO compilations will, however, send the LLVM module back to the coordinator thread once optimizations have finished. When all LLVM modules have finished optimizing the coordinator will invoke the LTO backend, producing a further list of LLVM modules. Currently this is always a list of one LLVM module. The coordinator then spawns further work to run LTO and code generation passes over each module. In the course of this refactoring a number of other pieces were refactored: * Management of the bytecode encoding in rlibs was centralized into one module instead of being scattered across LTO and linking. * Some internal refactorings on the link stage of the compiler was done to work directly from `CompiledModule` structures instead of lists of paths. * The trans time-graph output was tweaked a little to include a name on each bar and inflate the size of the bars a little
-
- 26 9月, 2017 1 次提交
-
-
由 Alex Crichton 提交于
This commit changes the default of rustc to use 32 codegen units when compiling in debug mode, typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit, gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things, using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above, but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This, however, doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized, but stay tuned if you're interested in that aspect!
-
- 18 9月, 2017 4 次提交
-
-
由 Alex Crichton 提交于
This commit moves the actual code generation in the compiler behind a query keyed by a codegen unit's name. This ended up entailing quite a few internal refactorings to enable this, along with a few cut corners: * The `OutputFilenames` structure is now tracked in the `TyCtxt` as it affects a whole bunch of trans and such. This is now behind a query and threaded into the construction of the `TyCtxt`. * The `TyCtxt` now has a channel "out the back" intended to send data to worker threads in rustc_trans. This is used as a sort of side effect of the codegen query but morally what's happening here is the return value of the query (currently unit but morally a path) is only valid once the background threads have all finished. * Dispatching work items to the codegen threads was refactored to only rely on data in `TyCtxt`, which mostly just involved refactoring where data was stored, moving it from the translation thread to the controller thread's `CodegenContext` or the like. * A new thread locals was introduced in trans to work around the query system. This is used in the implementation of `assert_module_sources` which looks like an artifact of the old query system and will presumably go away once red/green is up and running.
-
由 Alex Crichton 提交于
This commit attaches a channel to the LLVM workers to the `TyCtxt` which will later be used during the codegen query to actually send work to LLVM workers. Otherwise this commit is just plumbing this channel throughout the compiler to ensure it reaches the right consumers.
-
由 Alex Crichton 提交于
This is a big map that ends up inside of a `CrateContext` during translation for all codegen units. This means that any change to the map may end up causing an incremental recompilation of a codegen unit! In order to reduce the amount of dependencies here between codegen units and the actual input crate this commit refactors dealing with exported symbols and such into various queries. The new queries are largely based on existing queries with filled out implementations for the local crate in addition to external crates, but the main idea is that while translating codegen untis no unit needs the entire set of exported symbols, instead they only need queries about particulare `DefId` instances every now and then. The linking stage, however, still generates a full list of all exported symbols from all crates, but that's going to always happen unconditionally anyway, so no news there!
-
由 Alex Crichton 提交于
This commit moves the definition of the `ExportedSymbols` structure to the `rustc` crate and then creates a query that'll be used to construct the `ExportedSymbols` set. This in turn uses the reachablity query exposed in the previous commit.
-
- 15 9月, 2017 1 次提交
-
-
由 Alex Crichton 提交于
This commit removes the `dep_graph` field from the `Session` type according to issue #44390. Most of the fallout here was relatively straightforward and the `prepare_session_directory` function was rejiggered a bit to reuse the results in the later-called `load_dep_graph` function. Closes #44390
-
- 05 9月, 2017 2 次提交
-
-
由 Alex Crichton 提交于
The main use of `CrateStore` *before* the `TyCtxt` is created is during resolution, but we want to be sure that any methods used before resolution are not used after the `TyCtxt` is created. This commit starts moving the methods used by resolve to all be named `{name}_untracked` where the rest of the compiler uses just `{name}` as a query. During this transition a number of new queries were added to account for post-resolve usage of these methods.
-
由 Alex Crichton 提交于
This comit applies the following changes: * Deletes the `is_allocator` query as it's no longer used * Moves the `is_sanitizer_runtime` method to a query * Moves the `is_profiler_runtime` method to a query * Moves the `panic_strategy` method to a query * Moves the `is_no_builtins` method to a query * Deletes the cstore method of `is_compiler_builtins`. The query was added in #42588 but the `CrateStore` method was not deleted A good bit of these methods were used late in linking during trans so a new dedicated structure was created to ship a calculated form of this information over to the linker rather than having to ship the whole of `TyCtxt` over to linking.
-
- 19 8月, 2017 1 次提交
-
-
由 Vadim Petrochenkov 提交于
-
- 16 8月, 2017 1 次提交
-
-
由 Zack M. Davis 提交于
Like #43008 (f6689991), but _much more aggressive_.
-
- 10 8月, 2017 1 次提交
-
-
由 Michael Woerister 提交于
-
- 01 8月, 2017 1 次提交
-
-
由 Michael Woerister 提交于
-
- 31 7月, 2017 19 次提交
-
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
async-llvm(6): Make the LLVM work coordinator get its work package through a channel instead of upfront.
-
由 Michael Woerister 提交于
-