about summary refs log tree commit diff
path: root/src/librustc_codegen_llvm/back/lto.rs
AgeCommit message (Collapse)AuthorLines
2020-08-30mv compiler to compiler/mark-1075/+0
2020-08-06Incorporate tracing cratebishtpawan-1/+1
2020-07-10Avoid "whitelist"Tamir Duberstein-20/+37
Other terms are more inclusive and precise.
2020-06-25Prepare for LLVM 11Josh Stone-2/+3
2020-05-02cleanup: `config::CrateType` -> `CrateType`Vadim Petrochenkov-7/+4
2020-04-29Store LLVM bitcode in object files, not compressedAlex Crichton-16/+32
This commit is an attempted resurrection of #70458 where LLVM bitcode emitted by rustc into rlibs is stored into object file sections rather than in a separate file. The main rationale for doing this is that when rustc emits bitcode it will no longer use a custom compression scheme which makes it both easier to interoperate with existing tools and also cuts down on compile time since this compression isn't happening. The blocker for this in #70458 turned out to be that native linkers didn't handle the new sections well, causing the sections to either trigger bugs in the linker or actually end up in the final linked artifact. This commit attempts to address these issues by ensuring that native linkers ignore the new sections by inserting custom flags with module-level inline assembly. Note that this does not currently change the API of the compiler at all. The pre-existing `-C bitcode-in-rlib` flag is co-opted to indicate whether the bitcode should be present in the object file or not. Finally, note that an important consequence of this commit, which is also one of its primary purposes, is to enable rustc's `-Clto` bitcode loading to load rlibs produced with `-Clinker-plugin-lto`. The goal here is that when you're building with LTO Cargo will tell rustc to skip codegen of all intermediate crates and only generate LLVM IR. Today rustc will generate both object code and LLVM IR, but the object code is later simply thrown away, wastefully.
2020-04-20Expand comment to justify not checking if all the exports are green.Felix S. Klock II-0/+17
2020-04-17Issue #71248: attempt to recover perf by removing `exports_all_green` flag.Felix S. Klock II-10/+5
(My hypothesis is that my use of this flag was an overly conservative generalization of PR 67020.)
2020-04-15Incorporated review feedback:Felix S. Klock II-22/+40
Renamed the struct to make it a little clearer that it doesn't just hold one imports map. (I couldn't bring myself to write it as `ThinLTOImportsExports` though, mainly since the exports map is literally derived from the imports map data.) Added some doc to the struct too. Revised comments to add link to the newer issue that discusses why the exports are relevant. Renamed a few of the methods so that the two character difference is more apparent (because 1. the method name is shorter and, perhaps more importantly, the changed characters now lie at the beginning of the method name.)
2020-04-14If an LLVM module's exports change, cannot reuse its post-LTO object file inFelix S. Klock II-4/+33
incremental compilation. This is symmetric to PR #67020, which handled the case where the LLVM module's *imports* changed. This commit builds upon the infrastructure added there; the export map is just the inverse of the import map, so we can build the export map at the same time that we load the serialized import map. Fix #69798
2020-03-30rustc -> rustc_middle part 3 (rustfmt)Mazdak Farrokhzad-3/+3
2020-03-30rustc -> rustc_middle part 2Mazdak Farrokhzad-3/+3
2020-03-16use direct imports for `rustc::{lint, session}`.Mazdak Farrokhzad-1/+1
2020-03-06fix various typosMatthias Krüger-2/+2
2020-02-29Rollup merge of #69551 - matthiaskrgr:len_zero, r=Mark-SimulacrumDylan DPC-1/+1
use is_empty() instead of len() == x to determine if structs are empty.
2020-02-28use is_empty() instead of len() == x to determine if structs are empty.Matthias Krüger-1/+1
2020-02-27use char instead of &str for single char patternsMatthias Krüger-1/+1
2020-02-13add selfprofiling for new llvm passmanagerAndreas Jonson-1/+1
2020-02-12Add support for new pass managerNikita Popov-0/+14
The new pass manager can be enabled using -Z new-llvm-pass-manager=on.
2020-02-10self-profile: Support arguments for generic_activities.Michael Woerister-25/+32
2020-01-09Change -Z time event naming scheme and make them generic activitiesJohn Kåre Alsaker-6/+8
2020-01-05Remove rustc_hir reexports in rustc::hir.Mazdak Farrokhzad-1/+1
2020-01-05Use self profile infrastructure for -Z time and -Z time-passesJohn Kåre Alsaker-7/+5
2019-12-22Format the worldMark Rousskov-201/+176
2019-12-20save LTO import information and check it when trying to reuse build products.Felix S. Klock II-10/+114
adopts simple strategy devised with assistance from mw: Instead of accumulating (and acting upon) LTO import information over an unbounded number of prior compilations, just see if the current import set matches the previous import set. if they don't match, then you cannot reuse the PostLTO build product for that module. In either case (of a match or a non-match), we can (and must) unconditionally emit the current import set as the recorded information in the incremental compilation cache, ready to be loaded during the next compiler run for use in the same check described above. resolves issue 59535.
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.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-25 11:32:31 +0000