rust/tests/run-make/sepcomp-cci-copies/Makefile

include ../tools.mk

# Check that cross-crate inlined items are inlined in all compilation units
# that refer to them, and not in any other compilation units.
# Note that we have to pass `-C codegen-units=6` because up to two CGUs may be
# created for each source module (see `rustc_const_eval::monomorphize::partitioning`).

all:
	$(RUSTC) cci_lib.rs
	$(RUSTC) foo.rs --emit=llvm-ir -C codegen-units=6 \
		-Z inline-in-all-cgus
	[ "$$(cat "$(TMPDIR)"/foo.*.ll | grep -c define\ .*cci_fn)" -eq "2" ]
Diagnose missing includes in run-make tests 2022-08-22 19:00:00 -05:00			`include ../tools.mk`
add tests for separate compilation 2014-08-01 17:45:24 -05:00
			`# Check that cross-crate inlined items are inlined in all compilation units`
			`# that refer to them, and not in any other compilation units.`
test: use the right amount of CGUs in sepcomp-cci-copies to ensure deterministic splitting. 2018-02-07 13:27:37 -06:00			# Note that we have to pass `-C codegen-units=6` because up to two CGUs may be
Rename rustc_mir to rustc_const_eval. 2021-01-05 13:08:11 -06:00			# created for each source module (see `rustc_const_eval::monomorphize::partitioning`).
add tests for separate compilation 2014-08-01 17:45:24 -05:00
			`all:`
			`$(RUSTC) cci_lib.rs`
test: use the right amount of CGUs in sepcomp-cci-copies to ensure deterministic splitting. 2018-02-07 13:27:37 -06:00			`$(RUSTC) foo.rs --emit=llvm-ir -C codegen-units=6 \`
rustc: Don't inline in CGUs at -O0 This commit tweaks the behavior of inlining functions into multiple codegen units when rustc is compiling in debug mode. Today rustc will unconditionally treat `#[inline]` functions by translating them into all codegen units that they're needed within, marking the linkage as `internal`. This commit changes the behavior so that in debug mode (compiling at `-O0`) rustc will instead only translate `#[inline]` functions into one codegen unit, forcing all other codegen units to reference this one copy. The goal here is to improve debug compile times by reducing the amount of translation that happens on behalf of multiple codegen units. It was discovered in #44941 that increasing the number of codegen units had the adverse side effect of increasing the overal work done by the compiler, and the suspicion here was that the compiler was inlining, translating, and codegen'ing more functions with more codegen units (for example `String` would be basically inlined into all codegen units if used). The strategy in this commit should reduce the cost of `#[inline]` functions to being equivalent to one codegen unit, which is only translating and codegen'ing inline functions once. Collected [data] shows that this does indeed improve the situation from [before] as the overall cpu-clock time increases at a much slower rate and when pinned to one core rustc does not consume significantly more wall clock time than with one codegen unit. One caveat of this commit is that the symbol names for inlined functions that are only translated once needed some slight tweaking. These inline functions could be translated into multiple crates and we need to make sure the symbols don't collideA so the crate name/disambiguator is mixed in to the symbol name hash in these situations. [data]: https://github.com/rust-lang/rust/issues/44941#issuecomment-334880911 [before]: https://github.com/rust-lang/rust/issues/44941#issuecomment-334583384 2017-10-06 16:59:33 -05:00			`-Z inline-in-all-cgus`
rustc: Implement ThinLTO 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! 2017-07-23 10:14:38 -05:00			`[ "$$(cat "$(TMPDIR)"/foo..ll \| grep -c define\ .cci_fn)" -eq "2" ]`