refactor WorkerLocal for parallel compiler

[SparrowLii]

part of #101566
This PR refactor WorkerLocal for parallel compiler, facilitating code review and perf test.

ps. refactored WorkerLocal is not Send or Sync. It depends on #107586 to get thread safety.

[rustbot]

r? @cjgillot

(rustbot has picked a reviewer for you, use r? to override)

[SparrowLii]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 477e410 with merge fe80553693db52675c166e07a4e745050855ba41...

[deltragon]

This seems dangerous...
I am not entirely sure if the semantics of this have been fixed yet, but reading https://github.com/rust-lang/unsafe-code-guidelines/blob/master/active_discussion/validity.md it seems like this would be UB under that (since the assignment does a typed copy at type T, which does not allow uninit).
Either way, this is certainly a pattern that is discouraged, and it seems like the compiler should set an example here...
It seems much better to use a union between inner and mt_inner here, since it is guaranteed to only access the right field. (Or even better, an enum, since single_thread then functions as a discriminant... which basically makes it a homegrown enum anyways)

[RossSmyth]

Yeah this is very unsound because rustc emits noundef for almost all types. So this is immediately UB from LLVM's PoV, and the current thought for Rust rules (with no real thoughts on it not being UB in the future).

[SparrowLii]

It makes sense. I am a little worried about the efficiency of using enum or union, maybe it is better to use inner: Option<T> here

[deltragon]

I don't quite understand what the efficiency problem of an enum or union would be - checking the discriminant of an enum should be basically the same as checking if self.single_thread {, right?
(Additionally, using an Option would add increase the size by adding the Options discriminant in addition to single_thread)
I have opened #109528 to test the performance of my suggestion.

[SparrowLii]

Using enum will prevent LLVM from making the best optimizations in many cases. For example, the perf result of this commit: #101566 (comment)

And the use of union will cause the compiler to add a lot of stuffs that trigger unwind due to union access errors, which will also reduce the optimization effect.

[deltragon]

But Option is also an enum, so it should have the same effect?

[SparrowLii]

We can use unwrap which is a const function when signle_thread so i guess it is relatively more efficient

[bors]

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

[rust-timer]

Finished benchmarking commit (fe80553693db52675c166e07a4e745050855ba41): 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-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.

	mean	range	count
Regressions ❌ (primary)	0.6%	[0.3%, 1.0%]	6
Regressions ❌ (secondary)	0.5%	[0.3%, 0.8%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.7%	[-4.6%, -0.3%]	14
All ❌✅ (primary)	0.6%	[0.3%, 1.0%]	6

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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.6%	[0.4%, 0.7%]	5
Improvements ✅ (primary)	-1.5%	[-2.2%, -0.9%]	2
Improvements ✅ (secondary)	-1.1%	[-1.1%, -1.1%]	1
All ❌✅ (primary)	-1.5%	[-2.2%, -0.9%]	2

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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.9%	[0.5%, 1.2%]	9
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.8%	[-0.8%, -0.8%]	1
All ❌✅ (primary)	-	-	0

[Zoxc]

Keep in mind that this needs to be an improvement with #107782 applied.

[SparrowLii]

I think we will finish this work this month

[SparrowLii]

close this as it's already landed

#117435