summary refs log tree commit diff
path: root/src/librustc_codegen_llvm/back/lto.rs
AgeCommit message (Collapse)AuthorLines
2019-12-11rustc: Link LLVM directly into rustc againAlex Crichton-1/+3
This commit builds on #65501 continue to simplify the build system and compiler now that we no longer have multiple LLVM backends to ship by default. Here this switches the compiler back to what it once was long long ago, which is linking LLVM directly to the compiler rather than dynamically loading it at runtime. The `codegen-backends` directory of the sysroot no longer exists and all relevant support in the build system is removed. Note that `rustc` still supports a dynamically loaded codegen backend as it did previously, it just no longer supports dynamically loaded codegen backends in its own sysroot. Additionally as part of this the `librustc_codegen_llvm` crate now once again explicitly depends on all of its crates instead of implicitly loading them through the sysroot. This involved filling out its `Cargo.toml` and deleting all the now-unnecessary `extern crate` annotations in the header of the crate. (this in turn required adding a number of imports for names of macros too). The end results of this change are: * Rustbuild's build process for the compiler as all the "oh don't forget the codegen backend" checks can be easily removed. * Building `rustc_codegen_llvm` is much simpler since it's simply another compiler crate. * Managing the dependencies of `rustc_codegen_llvm` is much simpler since it's "just another `Cargo.toml` to edit" * The build process should be a smidge faster because there's more parallelism in the main rustc build step rather than splitting `librustc_codegen_llvm` out to its own step. * The compiler is expected to be slightly faster by default because the codegen backend does not need to be dynamically loaded. * Disabling LLVM as part of rustbuild is still supported, supporting multiple codegen backends is still supported, and dynamic loading of a codegen backend is still supported.
2019-12-03Move cgu_reuse_tracker to librustc_sessionMark Rousskov-1/+1
2019-11-29Use LLVMAddAnalysisPasses instead of Rust's wrapperVictor Ding-1/+1
LLVM exposes a C API `LLVMAddAnalysisPasses` and hence Rust's own wrapper `LLVMRustAddAnalysisPasses` is not needed anymore.
2019-10-18Avoid realloc in `CString::new`Shotaro Yamada-3/+1
2019-10-08Rollup merge of #65081 - Mark-Simulacrum:remove-profile-queries, ↵Mazdak Farrokhzad-3/+3
r=michaelwoerister Remove -Zprofile-queries r? @michaelwoerister Per [zulip thread](https://zulip-archive.rust-lang.org/131828tcompiler/57361RemoveZprofilequeries.html).
2019-10-05Replaces some instances of `as *[const | mut] _` with `.cast()`memoryruins-3/+3
2019-10-03Remove -Zprofile-queriesMark Rousskov-3/+3
2019-09-30Self-Profiling: Make names of existing events more consistent and use new API.Michael Woerister-43/+62
2019-08-27rustc: Handle modules in "fat" LTO more robustlyAlex Crichton-45/+41
When performing a "fat" LTO the compiler has a whole mess of codegen units that it links together. To do this it needs to select one module as a "base" module and then link everything else into this module. Previously LTO passes assume that there's at least one module in-memory to link into, but nowadays that's not always true! With incremental compilation modules may actually largely be cached and it may be possible that there's no in-memory modules to work with. This commit updates the logic of the LTO backend to handle modules a bit more uniformly during a fat LTO. This commit immediately splits them into two lists, one serialized and one in-memory. The in-memory list is then searched for the largest module and failing that we simply deserialize the first serialized module and link into that. This refactoring avoids juggling three lists, two of which are serialized modules and one of which is half serialized and half in-memory. Closes #63349
2019-08-08Explain why we're sorting the modules.Joel Galenson-0/+1
2019-08-08Sort fat LTO modules later and add a test.Joel Galenson-2/+4
2019-06-15Remove unnecessary `.clone()`Shotaro Yamada-1/+1
2019-04-20Move some filename constants to cg_ssabjorn3-2/+2
2019-04-12Use measureme in self-profilerWesley Wiser-7/+3
Related to #58372 Related to #58967
2019-03-10Replace TimeLine with SelfProfilerWesley Wiser-30/+14
2019-02-18librustc_codegen_llvm => 2018Taiki Endo-8/+7
2019-02-14Rollup merge of #58378 - alexcrichton:incremental-lto, r=michaelwoeristerMazdak Farrokhzad-38/+101
rustc: Implement incremental "fat" LTO Currently the compiler will produce an error if both incremental compilation and full fat LTO is requested. With recent changes and the advent of incremental ThinLTO, however, all the hard work is already done for us and it's actually not too bad to remove this error! This commit updates the codegen backend to allow incremental full fat LTO. The semantics are that the input modules to LTO are all produce incrementally, but the final LTO step is always done unconditionally regardless of whether the inputs changed or not. The only real incremental win we could have here is if zero of the input modules changed, but that's so rare it's unlikely to be worthwhile to implement such a code path. cc #57968 cc rust-lang/cargo#6643
2019-02-13Rollup merge of #58057 - michaelwoerister:stabilize-xlto, r=alexcrichtonMazdak Farrokhzad-1/+1
Stabilize linker-plugin based LTO (aka cross-language LTO) This PR stabilizes [linker plugin based LTO](https://github.com/rust-lang/rust/issues/49879), also known as "cross-language LTO" because it allows for doing inlining and other optimizations across language boundaries in mixed Rust/C/C++ projects. As described in the tracking issue, it works by making `rustc` emit LLVM bitcode instead of machine code, the same as `clang` does. A linker with the proper plugin (like LLD) can then run (Thin)LTO across all modules. The feature has been implemented over a number of pull requests and there are various [codegen](https://github.com/rust-lang/rust/blob/master/src/test/codegen/no-dllimport-w-cross-lang-lto.rs) and [run](https://github.com/rust-lang/rust/tree/master/src/test/run-make-fulldeps/cross-lang-lto-clang)-[make](https://github.com/rust-lang/rust/tree/master/src/test/run-make-fulldeps/cross-lang-lto-upstream-rlibs) [tests](https://github.com/rust-lang/rust/tree/master/src/test/run-make-fulldeps/cross-lang-lto) that make sure that it keeps working. It also works for building big projects like [Firefox](https://treeherder.mozilla.org/#/jobs?repo=try&revision=2ce2d5ddcea6fbff790503eac406954e469b2f5d). The PR makes the feature available under the `-C linker-plugin-lto` flag. As discussed in the tracking issue it is not cross-language specific and also not LLD specific. `-C linker-plugin-lto` is descriptive of what it does. If someone has a better name, let me know `:)`
2019-02-12Stabilize linker-plugin based LTO.Michael Woerister-1/+1
2019-02-12rustc: Implement incremental "fat" LTOAlex Crichton-38/+101
Currently the compiler will produce an error if both incremental compilation and full fat LTO is requested. With recent changes and the advent of incremental ThinLTO, however, all the hard work is already done for us and it's actually not too bad to remove this error! This commit updates the codegen backend to allow incremental full fat LTO. The semantics are that the input modules to LTO are all produce incrementally, but the final LTO step is always done unconditionally regardless of whether the inputs changed or not. The only real incremental win we could have here is if zero of the input modules changed, but that's so rare it's unlikely to be worthwhile to implement such a code path. cc #57968 cc rust-lang/cargo#6643
2019-02-10rustc: doc commentsAlexander Regueiro-1/+1
2019-01-24Implement optimize(size) and optimize(speed)Simonas Kazlauskas-2/+2
2018-12-25Remove licensesMark Rousskov-10/+0
2018-12-04Serialize modules into ThinBuffer after initial optimizationNikita Popov-32/+33
Instead of keeping all modules in memory until thin LTO and only serializing them then, serialize the module immediately after it finishes optimizing.
2018-12-04Remove unnecessary parts of run_fat_lto signatureNikita Popov-12/+5
Fat LTO merges into one module, so only return one module.
2018-12-04Separate out methods for running thin and fat LTONikita Popov-37/+50
2018-12-03codegen_llvm_back: improve allocationsljedrz-8/+10
2018-11-16[eddyb] rustc_codegen_ssa: rename `interfaces` to `traits`.Eduard-Mihai Burtescu-1/+1
2018-11-16[eddyb] rustc_codegen_ssa: avoid a `Clone` bound on `TargetMachine`.Eduard-Mihai Burtescu-1/+1
2018-11-16Separating the back folder between backend-agnostic and LLVM-specific codeDenis Merigoux-260/+164
2018-11-16Beginning of moving all backend-agnostic code to rustc_codegen_ssaDenis Merigoux-1/+1
2018-11-16Moved Backend interface into rustc_codegen_utilsDenis Merigoux-1/+2
2018-11-16Generalized base:codegen_crateDenis Merigoux-8/+7
2018-11-16Removed phantomdata no longer necessaryDenis Merigoux-2/+0
Because CodegenContext doesn't implement Backend anymore
2018-11-16CommonWriteMethods are not static any moreDenis Merigoux-0/+2
2018-11-11Auto merge of #55698 - nikic:remove-llvm-4-support, r=alexcrichtonbors-3/+1
Remove support for building against LLVM 4 With emscripten removed in #55626, we no longer need to support building against LLVM 4.
2018-11-10codegen_llvm_back: improve common patternsljedrz-8/+2
2018-11-10codegen_llvm_back: use Cow<'static, str> where applicableljedrz-9/+9
2018-11-10codegen_llvm_back: whitespace & formatting fixesljedrz-9/+8
2018-11-06Run name-anon-globals after LTO passes as wellNikita Popov-0/+7
If we're going to emit bitcode (through ThinLTOBuffer), then we need to ensure that anon globals are named. This was already done after optimization passes, but also has to happen after LTO passes, as we always emit the final result in a ThinLTO-compatible manner. Fixes #51947.
2018-11-05Remove support for building against LLVM 4Nikita Popov-3/+1
With emscripten removed in #55626, we no longer need to support building against LLVM 4.
2018-11-03Move cg_llvm::back::linker to cg_utilsbjorn3-1/+1
2018-10-23Revert "rustc: Fix (again) simd vectors by-val in ABI"Alex Crichton-5/+7
This reverts commit 3cc8f738d4247a9b475d8e074b621e602ac2b7be.
2018-10-20Rollup merge of #55073 - alexcrichton:demote-simd, r=nagisaManish Goregaokar-7/+5
The issue of passing around SIMD types as values between functions has seen [quite a lot] of [discussion], and although we thought [we fixed it][quite a lot] it [wasn't]! This PR is a change to rustc to, again, try to fix this issue. The fundamental problem here remains the same, if a SIMD vector argument is passed by-value in LLVM's function type, then if the caller and callee disagree on target features a miscompile happens. We solve this by never passing SIMD vectors by-value, but LLVM will still thwart us with its argument promotion pass to promote by-ref SIMD arguments to by-val SIMD arguments. This commit is an attempt to thwart LLVM thwarting us. We, just before codegen, will take yet another look at the LLVM module and demote any by-value SIMD arguments we see. This is a very manual attempt by us to ensure the codegen for a module keeps working, and it unfortunately is likely producing suboptimal code, even in release mode. The saving grace for this, in theory, is that if SIMD types are passed by-value across a boundary in release mode it's pretty unlikely to be performance sensitive (as it's already doing a load/store, and otherwise perf-sensitive bits should be inlined). The implementation here is basically a big wad of C++. It was largely copied from LLVM's own argument promotion pass, only doing the reverse. In local testing this... Closes #50154 Closes #52636 Closes #54583 Closes #55059 [quite a lot]: https://github.com/rust-lang/rust/pull/47743 [discussion]: https://github.com/rust-lang/rust/issues/44367 [wasn't]: https://github.com/rust-lang/rust/issues/50154
2018-10-19Prefer `Default::default` over `FxHash*::default` in struct constructorsOliver Scherer-11/+3
2018-10-19Deprecate the `FxHashMap()` and `FxHashSet()` constructor function hackOliver Scherer-2/+2
2018-10-19rustc: Fix (again) simd vectors by-val in ABIAlex Crichton-7/+5
The issue of passing around SIMD types as values between functions has seen [quite a lot] of [discussion], and although we thought [we fixed it][quite a lot] it [wasn't]! This PR is a change to rustc to, again, try to fix this issue. The fundamental problem here remains the same, if a SIMD vector argument is passed by-value in LLVM's function type, then if the caller and callee disagree on target features a miscompile happens. We solve this by never passing SIMD vectors by-value, but LLVM will still thwart us with its argument promotion pass to promote by-ref SIMD arguments to by-val SIMD arguments. This commit is an attempt to thwart LLVM thwarting us. We, just before codegen, will take yet another look at the LLVM module and demote any by-value SIMD arguments we see. This is a very manual attempt by us to ensure the codegen for a module keeps working, and it unfortunately is likely producing suboptimal code, even in release mode. The saving grace for this, in theory, is that if SIMD types are passed by-value across a boundary in release mode it's pretty unlikely to be performance sensitive (as it's already doing a load/store, and otherwise perf-sensitive bits should be inlined). The implementation here is basically a big wad of C++. It was largely copied from LLVM's own argument promotion pass, only doing the reverse. In local testing this... Closes #50154 Closes #52636 Closes #54583 Closes #55059 [quite a lot]: https://github.com/rust-lang/rust/pull/47743 [discussion]: https://github.com/rust-lang/rust/issues/44367 [wasn't]: https://github.com/rust-lang/rust/issues/50154
2018-09-18incr.comp.: Allow for more fine-grained testing of CGU reuse and use it to ↵Michael Woerister-0/+3
test incremental ThinLTO.
2018-09-14Rollup merge of #53950 - michaelwoerister:more-lto-cli, r=alexcrichtonkennytm-2/+1
Allow for opting out of ThinLTO and clean up LTO related cli flag handling. It turns out that there currently is no way to explicitly disable ThinLTO (except for the nightly-only `-Zthinlto` flag). This PR extends `-C lto` to take `yes` and `no` in addition to `thin` and `fat`. It should be backwards compatible. It also cleans up how LTO mode selection is handled. Note that merging the PR in the current state would make the new values for `-C lto` available on the stable channel. I think that would be fine but maybe some team should vote on it.
2018-09-05ThinLTO: Don't keep files open after mmaping them (because it's not needed).Michael Woerister-3/+3
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-13 16:14:28 +0000