Store a DefId instead of an AdtDef in AggregateKind::Adt

[Aaron1011]

The AggregateKind enum ends up in the final mir Body. Currently,
any changes to AdtDef (regardless of how significant they are)
will legitimately cause the overall result of optimized_mir to change,
invalidating any codegen re-use involving that mir.

This will get worse once we start hashing the Span inside FieldDef
(which is itself contained in AdtDef).

To try to reduce these kinds of invalidations, this commit changes
AggregateKind::Adt to store just the DefId, instead of the full
AdtDef. This allows the result of optimized_mir to be unchanged
if the AdtDef changes in a way that doesn't actually affect any
of the MIR we build.

[rust-highfive]

Some changes occured to the CTFE / Miri engine

cc @rust-lang/miri

[rust-highfive]

r? @oli-obk

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

[Aaron1011]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit cac431b with merge f525b58008e58fa0b4809a7102f4ebd2e14c1047...

[bors]

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

[rust-timer]

Queued f525b58008e58fa0b4809a7102f4ebd2e14c1047 with parent e100ec5, future comparison URL.

[rust-timer]

Finished benchmarking commit (f525b58008e58fa0b4809a7102f4ebd2e14c1047): comparison url.

Summary: This benchmark run did not return any relevant changes.

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.

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

[oli-obk]

@bors r+ rollup

I think we should try and follow up on this by attempting to reduce the number of tcx.adt_def calls where possible. It may be unnecessary in const checking and other places, even if the function signatures currently require it. We could check how the AdtDef is used later. All the is_enum cases could potentially obtain this information from local caches (e.g. in mir interpret we can ask for the type of the local)

[bors]

📌 Commit cac431b has been approved by oli-obk

[oli-obk]

@bors r-

Ah what I forgot: is it now possible to write incremental tests that show that this causes fewer recompiles of optimized_mir?

[oli-obk]

r=me with an answer to that

[Aaron1011]

@oli-obk Since we currently skip hashing the FieldDef span, I dont know if this will curreny prevent any invalidations. Once we start hashing spans in #92210, this will become important

[oli-obk]

I thought so, thanks for confirming

@bors r+

[bors]

📌 Commit cac431b has been approved by oli-obk