about summary refs log tree commit diff
path: root/src/librustc_codegen_ssa/back/write.rs
AgeCommit message (Collapse)AuthorLines
2019-06-12Run `rustfmt --file-lines ...` for changes from previous commits.Eduard-Mihai Burtescu-8/+10
2019-06-12rustc: replace `TyCtxt<'tcx, 'gcx, 'tcx>` with `TyCtxt<'gcx, 'tcx>`.Eduard-Mihai Burtescu-8/+8
2019-05-28Rename PgoGenerate to something more general.Michael Woerister-3/+3
2019-05-27Use a PathBuf instead of String for representing the pgo-use path internally.Michael Woerister-2/+2
2019-05-16add targetarch for CodegenContextChandler Deng-0/+2
2019-05-13Remove the equality operation between `Symbol` and strings.Nicholas Nethercote-1/+1
And also the equality between `Path` and strings, because `Path` is made up of `Symbol`s.
2019-05-13Pass a `Symbol` to `check_name`, `emit_feature_err`, and related functions.Nicholas Nethercote-3/+3
2019-04-30In JSON output, emit a directive after metadata is generated.Nicholas Nethercote-2/+2
To implement pipelining, Cargo needs to know when metadata generation is finished. This commit adds code to do that. Unfortunately, metadata file writing currently occurs very late during compilation, so pipelining won't produce a speed-up. Moving metadata file writing earlier will be a follow-up. The change involves splitting the existing `Emitter::emit` method in two: `Emitter::emit_diagnostic` and `Emitter::emit_directive`. The JSON directives look like this: ``` {"directive":"metadata file written: liba.rmeta"} ``` The functionality is behind the `-Z emit-directives` option, and also requires `--error-format=json`.
2019-04-24Don't generate unnecessary rmeta files.Nicholas Nethercote-6/+5
2019-04-14Rollup merge of #59874 - michaelwoerister:pgo-updates-1, r=cramertjMazdak Farrokhzad-3/+4
Clean up handling of `-Z pgo-gen` commandline option. This PR adapts the `-Z pgo-gen` flag to how Clang and GCC handle the corresponding `-fprofile-generate` flag. In particular, the flag now optionally takes a directory to place the profiling data in and allows to omit the argument (instead of having to pass an empty string).
2019-04-12Use measureme in self-profilerWesley Wiser-23/+14
Related to #58372 Related to #58967
2019-04-11Clean up handling of -Zpgo-gen commandline option.Michael Woerister-3/+4
2019-04-01Rollup merge of #58507 - Zoxc:time-extended, r=michaelwoeristerMazdak Farrokhzad-2/+2
Add a -Z time option which prints only passes which runs once This ensures `-Z time-passes` fits on my screen =P r? @michaelwoerister
2019-03-27Use informational target machine for metadataSimonas Kazlauskas-1/+7
Since there is nothing to optimise there...
2019-03-20Add a -Z time option which prints only passes which runs onceJohn Kåre Alsaker-2/+2
2019-03-10Replace TimeLine with SelfProfilerWesley Wiser-48/+65
2019-03-06Make `-Z treat-err-as-bug` take a number of errors to be emittedEsteban Küber-1/+1
`-Z treat-err-as-bug=0` will cause `rustc` to panic after the first error is reported. `-Z treat-err-as-bug=2` will cause `rustc` to panic after 3 errors have been reported.
2019-03-03Wrap the self-profiler in an `Arc<Mutex<>>`Wesley Wiser-0/+24
This will allow us to send it across threads and measure things like LLVM time.
2019-02-25librustc_codegen_ssa: deny(elided_lifetimes_in_paths)Mazdak Farrokhzad-9/+9
2019-02-14Rollup merge of #58378 - alexcrichton:incremental-lto, r=michaelwoeristerMazdak Farrokhzad-17/+58
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-5/+5
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-12Auto merge of #58341 - alexreg:cosmetic-2-doc-comments, r=steveklabnikbors-2/+2
Cosmetic improvements to doc comments This has been factored out from https://github.com/rust-lang/rust/pull/58036 to only include changes to documentation comments (throughout the rustc codebase). r? @steveklabnik Once you're happy with this, maybe we could get it through with r=1, so it doesn't constantly get invalidated? (I'm not sure this will be an issue, but just in case...) Anyway, thanks for your advice so far!
2019-02-12Stabilize linker-plugin based LTO.Michael Woerister-5/+5
2019-02-12rustc: Implement incremental "fat" LTOAlex Crichton-17/+58
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-2/+2
2019-02-09librustc_codegen_ssa => 2018Taiki Endo-4/+3
2019-01-24Implement optimize(size) and optimize(speed)Simonas Kazlauskas-1/+2
2019-01-05Add a target option "merge-functions" taking values in ("disabled",Peter Jin-2/+19
"trampolines", or "aliases (the default)) to allow targets to opt out of the MergeFunctions LLVM pass. Also add a corresponding -Z option with the same name and values. This works around: https://github.com/rust-lang/rust/issues/57356 Motivation: Basically, the problem is that the MergeFunctions pass, which rustc currently enables by default at -O2 and -O3, and `extern "ptx-kernel"` functions (specific to the NVPTX target) are currently not compatible with each other. If the MergeFunctions pass is allowed to run, rustc can generate invalid PTX assembly (i.e. a PTX file that is not accepted by the native PTX assembler ptxas). Therefore we would like a way to opt out of the MergeFunctions pass, which is what our target option does. Related work: The current behavior of rustc is to enable MergeFunctions at -O2 and -O3, and also to enable the use of function aliases within MergeFunctions. MergeFunctions both with and without function aliases is incompatible with the NVPTX target. clang's "solution" is to have a "-fmerge-functions" flag that opts in to the MergeFunctions pass, but it is not enabled by default.
2018-12-25Remove licensesMark Rousskov-10/+0
2018-12-07Auto merge of #56502 - Zoxc:hir-func, r=eddybbors-2/+2
Use a function to access the Hir map to be able to turn it into a query later r? @eddyb
2018-12-06Use a function to access the Hir map to be able to turn it into a query laterJohn Kåre Alsaker-2/+2
2018-12-04Serialize modules into ThinBuffer after initial optimizationNikita Popov-15/+19
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-2/+4
Fat LTO merges into one module, so only return one module.
2018-12-04Separate out methods for running thin and fat LTONikita Popov-2/+2
2018-12-04Separate codepaths for fat and thin LTO in write.rsNikita Popov-27/+56
These are going to have different intermediate artifacts, so create separate codepaths for them.
2018-12-04Refactor LTO type determinationNikita Popov-35/+41
Instead of only determining whether some form of LTO is necessary, determine whether thin, fat or no LTO is necessary. I've rewritten the conditions in a way that I think is more obvious, i.e. specified LTO type + additional preconditions.
2018-12-04Extract free_worker closureNikita Popov-23/+18
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-3/+13
2018-11-16Separating the back folder between backend-agnostic and LLVM-specific codeDenis Merigoux-0/+1843
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-25 01:27:48 +0000