[Experiment] Don't merge vtables for improved debugging.

[michaelwoerister]

With this PR I'd like to test the performance and size impact of making vtables unique by removing the unnamed_addr attribute from them. Having unique vtables is good for debuginfo, because it allows to map from a dyn pointer to the self-type of the trait-object by looking at the vtable's debuginfo. If vtables are merged, we lose this ability because we might get the wrong self-type.

This PR disables vtable merging unconditionally, so we can see the impact on perf.rlo. An actual implementation would likely only disable it when full debuginfo is enabled.

r? @ghost

[michaelwoerister]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 0247c6a with merge 65f47026b47e75096d402bd8cd83f87bd1994c82...

[bors]

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

[rust-timer]

Queued 65f47026b47e75096d402bd8cd83f87bd1994c82 with parent 31d754a, future comparison URL.

[rust-timer]

Finished benchmarking commit (65f47026b47e75096d402bd8cd83f87bd1994c82): comparison URL.

Overall result: ✅ improvements - no 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.

@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)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.2%	[-1.2%, -1.2%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

This benchmark run did not return any relevant results for this metric.

Footnotes

1. the arithmetic mean of the percent change ↩

2. number of relevant changes ↩

[michaelwoerister]

OK, it looks like performance isn't noticeably affected by this change. I suspect that vtables already don't get merged that often, so the price of making sure it never happens shouldn't be too high.

I'll close this PR and open a cleaned-up version that just enables this when full debuginfo is requested.