Use fat LTO for compiling rustc

[Kobzol]

Based on earlier experiments, I think that this has a large effect on build time, but not so large effect on performance. Let's check.

r? @ghost

[Kobzol]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit 7db05e6 with merge 39b1a70a9d4345df1de45aa5b15bea4a7c1fada2...

[bors]

💥 Test timed out

[matthiaskrgr]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit 7db05e6 with merge 50910d67cdb37f31fe3f5369110d3d6912116756...

[bors]

☀️ Try build successful - checks-actions
Build commit: 50910d67cdb37f31fe3f5369110d3d6912116756 (50910d67cdb37f31fe3f5369110d3d6912116756)

[rust-timer]

Queued 50910d67cdb37f31fe3f5369110d3d6912116756 with parent 7feb003, future comparison URL.

[rust-timer]

Finished benchmarking commit (50910d67cdb37f31fe3f5369110d3d6912116756): comparison URL.

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf +perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean1	range	count2
Regressions ❌ (primary)	2.2%	[0.4%, 5.2%]	184
Regressions ❌ (secondary)	2.3%	[0.3%, 8.6%]	148
Improvements ✅ (primary)	-0.6%	[-1.0%, -0.2%]	10
Improvements ✅ (secondary)	-1.2%	[-2.4%, -0.4%]	23
All ❌✅ (primary)	2.1%	[-1.0%, 5.2%]	194

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean1	range	count2
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.9%	[-3.0%, -0.5%]	112
Improvements ✅ (secondary)	-3.0%	[-5.9%, -1.4%]	57
All ❌✅ (primary)	-1.9%	[-3.0%, -0.5%]	112

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean1	range	count2
Regressions ❌ (primary)	3.2%	[1.1%, 9.3%]	140
Regressions ❌ (secondary)	4.8%	[2.0%, 17.2%]	88
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.8%	[-8.2%, -2.1%]	9
All ❌✅ (primary)	3.2%	[1.1%, 9.3%]	140

Footnotes

1. the arithmetic mean of the percent change ↩ ↩² ↩³

2. number of relevant changes ↩ ↩² ↩³

[Kobzol]

Hmm, these results almost look like LTO being turned off.

[goolic]

Just a head-up that IMO this path is a dead end. Thin LTO is newer than FAT LTO and designed to enable more optimizations to be eventually be added.

More info:

See this talk by the designers of thin LTO

[Kobzol]

Thanks, I will definitely check that out! I also think that this might not lead anywhere, fat LTO compiles very slowly and I haven't seen any incredible performance improvements so far.

[Kobzol]

It doesn't seem like fat LTO is useful here at this moment.