Make Rc<T>::deref and Arc<T>::deref zero-cost

[EFanZh]

Currently, Rc<T> and Arc<T> store pointers to RcInner<T> and ArcInner<T>. This PR changes the pointers so that they point to T directly instead.

This is based on the assumption that we access the T value more frequently than accessing reference counts. With this change, accessing the data can be done without offsetting pointers from RcInner<T> and ArcInner<T> to their contained data. This change might also enables some possibly useful future optimizations, such as:

• Convert &[Rc<T>] into &[&T] within O(1) time.
• Convert &[Rc<T>] into Vec<&T> utilizing memcpy.
• Convert &Option<Rc<T>> into Option<&T> without branching.
• Make Rc<T> and Arc<T> FFI compatible types where T: Sized.

[rustbot]

r? @jhpratt

rustbot has assigned @jhpratt.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[marmeladema]

Would it potentially enable those types to have an ffi compatible ABI? So that they could be returned and passed directly from /to ffi function, like Box?

[EFanZh]

Would it potentially enable those types to have an ffi compatible ABI? So that they could be returned and passed directly from /to ffi function, like Box?

I think in theory it is possible, at least for sized types, but I am not familiar with how to formally make it so.

[jhpratt]

r? libs

[joboet]

@EFanZh Is this ready for review? If so, please un-draft the PR.

[EFanZh]

@joboet: The source code part is mostly done, but I haven’t finished updating LLDB and CDB pretty printers. The CI doesn’t seem to run those tests.

[joboet]

No worries! I just didn't want to keep you waiting in case you had forgotten to change the state.
@rustbot author

[bors]

☔ The latest upstream changes (presumably #135357) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #135396) made this pull request unmergeable. Please resolve the merge conflicts.

[EFanZh]

Hi @joboet: Can I request a perf run to see the impact of this change?

[joboet]

Sure thing!
@bors try @rust-timer queue

[bors]

⌛ Trying commit 5f9be42 with merge 00d0a00...

[bors]

☀️ Try build successful - checks-actions
Build commit: 00d0a00 (00d0a00da6ba18a6278cac0a20bafe752a181ad4)

[rust-timer]

Finished benchmarking commit (00d0a00): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

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-perf +perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	0.5%	[0.2%, 1.1%]	22
Regressions ❌ (secondary)	1.8%	[0.3%, 4.6%]	25
Improvements ✅ (primary)	-1.0%	[-2.2%, -0.4%]	3
Improvements ✅ (secondary)	-0.0%	[-0.0%, -0.0%]	1
All ❌✅ (primary)	0.3%	[-2.2%, 1.1%]	25

Max RSS (memory usage)

Results (primary 0.7%, secondary -0.5%)

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.

	mean	range	count
Regressions ❌ (primary)	3.5%	[1.5%, 5.6%]	7
Regressions ❌ (secondary)	2.8%	[2.0%, 4.8%]	4
Improvements ✅ (primary)	-3.3%	[-8.4%, -1.0%]	5
Improvements ✅ (secondary)	-2.6%	[-4.0%, -1.1%]	6
All ❌✅ (primary)	0.7%	[-8.4%, 5.6%]	12

Cycles

Results (primary -2.1%, secondary 3.0%)

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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.0%	[1.7%, 4.1%]	16
Improvements ✅ (primary)	-2.1%	[-2.1%, -2.1%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.1%	[-2.1%, -2.1%]	1

Binary size

Results (primary 0.4%, secondary 1.1%)

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.

	mean	range	count
Regressions ❌ (primary)	0.4%	[0.0%, 1.8%]	88
Regressions ❌ (secondary)	1.1%	[0.3%, 9.1%]	82
Improvements ✅ (primary)	-0.5%	[-1.3%, -0.2%]	5
Improvements ✅ (secondary)	-0.2%	[-0.2%, -0.2%]	1
All ❌✅ (primary)	0.4%	[-1.3%, 1.8%]	93

Bootstrap: 778.16s -> 777.103s (-0.14%)
Artifact size: 329.00 MiB -> 329.08 MiB (0.02%)

[scottmcm]

Hmm, odd to see both debug and opt binary sizes are bigger with this. Maybe try to find the cause there? Might just be a missing #[inline] somewhere...

[EFanZh]

@scottmcm: I’m working on it, but it may take some time since it’s being done in my free time.

[bors]

☔ The latest upstream changes (presumably #136751) made this pull request unmergeable. Please resolve the merge conflicts.