[WIP] cstore: Add a new caching layer for data decoded from resolver

[petrochenkov]

Implement something to address https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.22Querifying.22.20early.20cstore.20accesses/near/253737343

One obvious further optimization would be to use some kind of arena to avoid cloning heavy decoded data like vectors.

[rust-highfive]

r? @oli-obk

(rust-highfive has picked a reviewer for you, use r? to override)

[petrochenkov]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 0d937e9d79af47aeae19877210cc568285eae27a with merge 4dd94872d389336d4dbbb73ba19e70bcd9473a01...

[bors]

☀️ Try build successful - checks-actions
Build commit: 4dd94872d389336d4dbbb73ba19e70bcd9473a01 (4dd94872d389336d4dbbb73ba19e70bcd9473a01)

[rust-timer]

Queued 4dd94872d389336d4dbbb73ba19e70bcd9473a01 with parent a58db2e, future comparison URL.

[bjorn3]

DefKind is very cheap to decode I think.

rust/compiler/rustc_hir/src/def.rs

Lines 55 to 119 in c7dbe7a

	pubenumDefKind{
	// Type namespace
	Mod,
	/// Refers to the struct itself, [`DefKind::Ctor`] refers to its constructor if it exists.
	Struct,
	Union,
	Enum,
	/// Refers to the variant itself, [`DefKind::Ctor`] refers to its constructor if it exists.
	Variant,
	Trait,
	/// Type alias: `type Foo = Bar;`
	TyAlias,
	/// Type from an `extern` block.
	ForeignTy,
	/// Trait alias: `trait IntIterator = Iterator<Item = i32>;`
	TraitAlias,
	/// Associated type: `trait MyTrait { type Assoc; }`
	AssocTy,
	/// Type parameter: the `T` in `struct Vec<T> { ... }`
	TyParam,
	// Value namespace
	Fn,
	Const,
	/// Constant generic parameter: `struct Foo<const N: usize> { ... }`
	ConstParam,
	Static,
	/// Refers to the struct or enum variant's constructor.
	///
	/// The reason `Ctor` exists in addition to [`DefKind::Struct`] and
	/// [`DefKind::Variant`] is because structs and enum variants exist
	/// in the *type* namespace, whereas struct and enum variant *constructors*
	/// exist in the *value* namespace.
	///
	/// You may wonder why enum variants exist in the type namespace as opposed
	/// to the value namespace. Check out [RFC 2593] for intuition on why that is.
	///
	/// [RFC 2593]: https://github.com/rust-lang/rfcs/pull/2593
	Ctor(CtorOf,CtorKind),
	/// Associated function: `impl MyStruct { fn associated() {} }`
	AssocFn,
	/// Associated constant: `trait MyTrait { const ASSOC: usize; }`
	AssocConst,
	// Macro namespace
	Macro(MacroKind),
	// Not namespaced (or they are, but we don't treat them so)
	ExternCrate,
	Use,
	/// An `extern` block.
	ForeignMod,
	/// Anonymous constant, e.g. the `1 + 2` in `[u8; 1 + 2]`, or `const { 1 + 2}`
	AnonConst,
	/// Opaque type, aka `impl Trait`.
	OpaqueTy,
	Field,
	/// Lifetime parameter: the `'a` in `struct Foo<'a> { ... }`
	LifetimeParam,
	/// A use of [`global_asm!`].
	GlobalAsm,
	Impl,
	Closure,
	Generator,
	}

[rust-timer]

Finished benchmarking commit (4dd94872d389336d4dbbb73ba19e70bcd9473a01): comparison url.

Summary: This change led to large relevant mixed results 🤷 in compiler performance.

• Moderate improvement in instruction counts (up to -1.2% on full builds of coercions)
• Large regression in instruction counts (up to 4.8% on full builds of deeply-nested-closures)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

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 led 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

[petrochenkov]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 3c24f7cb3f1a0d4e420033e9cc962121ecb32667 with merge f764f6372fa6071b7d65617b2fc04123b516bdbf...

[bors]

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

[rust-timer]

Queued f764f6372fa6071b7d65617b2fc04123b516bdbf with parent 5438ee4, future comparison URL.

[rust-timer]

Finished benchmarking commit (f764f6372fa6071b7d65617b2fc04123b516bdbf): comparison url.

Summary: This change led to large relevant regressions 😿 in compiler performance.

• Large regression in instruction counts (up to 4.4% on full builds of deeply-nested)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

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 led 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

[bors]

☀️ Try build successful - checks-actions
Build commit: 6cc1b9a099c33502cb7d0d6f0df626a37b5997f9 (6cc1b9a099c33502cb7d0d6f0df626a37b5997f9)

[rust-timer]

Queued 6cc1b9a099c33502cb7d0d6f0df626a37b5997f9 with parent 60e70cc, future comparison URL.

[rust-timer]

Finished benchmarking commit (6cc1b9a099c33502cb7d0d6f0df626a37b5997f9): comparison url.

Summary: This change led to moderate relevant mixed results 🤷 in compiler performance.

• Moderate improvement in instruction counts (up to -1.2% on incr-unchanged builds of externs)
• Moderate regression in instruction counts (up to 1.6% on full builds of unify-linearly)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

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 led 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

[petrochenkov]

I'm not going to pursue this general mechanism anymore, given the results.
All the useful parts were extracted to #92156, #92159 and #92161.