summary refs log tree commit diff
path: root/src/librustc_codegen_llvm/back/lto.rs
AgeCommit message (Collapse)AuthorLines
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
2018-09-05Allow for opting out of ThinLTO and clean up LTO related cli flag handling.Michael Woerister-2/+1
2018-09-03incr.ThinLTO: Do some cleanup and add some logging.Michael Woerister-21/+33
2018-08-31Always add all modules to the global ThinLTO module analysis when compiling ↵Michael Woerister-138/+97
incrementally.
2018-08-31Support local ThinLTO with incremental compilation.Michael Woerister-20/+88
2018-08-31Persist ThinLTO import data in incr. comp. session directory.Michael Woerister-3/+116
2018-08-15Use CGU name as LLVM module name and add some caching to CGU name generation.Michael Woerister-6/+5
2018-08-07Fix issue around dllimport and ThinLTO as LLD runs it.Michael Woerister-0/+4
2018-08-04Normalize variants of CrateType to standard styleMark Rousskov-6/+6
This is a clippy-breaking change.
2018-07-31rustc: Handle linker diagnostic from LLVMAlex Crichton-2/+10
Previously linker diagnostic were being hidden when two modules were linked together but failed to link. This commit fixes the situation by ensuring that we have a diagnostic handler installed and also adds support for handling linker diagnostics.
2018-07-30rustc_codegen_llvm: use safe references for ThinLTOData.Irina Popa-7/+6
2018-07-30rustc_codegen_llvm: use safe references for ThinLTOBuffer.Irina Popa-2/+2
2018-07-30rustc_codegen_llvm: use safe references for ModuleBuffer.Irina Popa-2/+2
2018-07-30rustc_codegen_llvm: use safe references for Linker.Irina Popa-5/+5
2018-07-30rustc_codegen_llvm: use safe references for TargetMachine.Irina Popa-2/+2
2018-07-30rustc_codegen_llvm: use safe references for Pass.Irina Popa-4/+2
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-04-28 21:21:11 +0000