Use MaybeUninit in libcore

[RalfJung]

All code by @japaric. This re-submits the second half of #53508 (the first half is at #54667). This is likely the one containing the perf regression.

[rust-highfive]

r? @dtolnay

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

[RalfJung]

@bors try

[bors]

⌛ Trying commit 5f7792bf46e67c5e2277dbf3644e4ba5b34fac0f with merge 5e4ca24261a1348f3242d6885c8a286182b958b2...

[RalfJung]

(Looks like try is done but there was no notification about that? @rust-lang/infra )

@rust-timer build 5e4ca24261a1348f3242d6885c8a286182b958b2

[RalfJung]

@rust-timer build 5e4ca24261a1348f3242d6885c8a286182b958b2

(And there is no good way to copy-paste the commit SHA in one step)

[rust-timer]

Success: Queued 5e4ca24261a1348f3242d6885c8a286182b958b2 with parent 7e7bc06, comparison URL.

[dtolnay]

r? @RalfJung

[RalfJung]

@dtolnay Eh, I submitted this. I do not think I should review it.^^

[dtolnay]

You already reviewed this code in #53508. Please clarify what remains to be reviewed.

Assigning the same reviewer as #54667:
r? @cramertj

[RalfJung]

I wasn't aware of a policy for re-submissions of reverted PRs that would let me r+ this even though I assembled the commits.

And anyway I expect this PR will need changes because there will be perf regressions. But let's see.

[Valinora]

Perf results are in, this definitely looks to be the source of the regression.

[gnzlbg]

@RalfJung I don't know if this helps, but I don't see anything suspicious with this PR, so maybe the issue causing the regression is not here?

One "suspicious" thing is that the regression happens in liballoc, but MaybeUninit is declared in libcore and its methods are not #[inline], which means that they cannot reliably be inlined into other crates without some form of LTO. The functions being touched here are big, so maybe LTO is not inlining these?

If you look at the disassembly of these tests and see a call instruction pointing to the MaybeUninit methods in libcore, it might be worth testing whether making MaybeUninit methods #[inline] might fix this regression.

[RalfJung]

It's methods are generic though so #[inline] shouldn't make a difference, right?

the regression happens in liballoc

Where are you getting that from?

Unfortunately I will not have much time to work on this this week.

[gnzlbg]

It's methods are generic though so #[inline] shouldn't make a difference, right?

Indeed. The only way in which that could make a difference is if they call a non-generic function that is not #[inline], but it appears that this is not the case. I'm out of ideas.

Where are you getting that from?

I thought most of the changes here were in liballoc, but there are some changes in libcore as well. It might be worth it to figure out which of the changes (slice rotate, slice sort, ptr, liballoc's btree, etc.) introduces the regression.

[RalfJung]

I might be doing the wrong thing, but I failed to reproduce the perf regression... in fact, issue-46449 got 12% faster with this PR in my measurement:

$ hyperfine -w 1 -m 3 -p 'rm target -rf' 'cargo +stage1 build --release' 'cargo +stage1.2 build --release'
Benchmark #1: cargo +stage1 build --release

  Time (mean ± σ):      3.532 s ±  0.014 s    [User: 6.576 s, System: 0.115 s]
 
  Range (min … max):    3.520 s …  3.548 s
 
Benchmark #2: cargo +stage1.2 build --release

  Time (mean ± σ):      3.166 s ±  0.059 s    [User: 6.180 s, System: 0.137 s]
 
  Range (min … max):    3.122 s …  3.233 s
 
Summary

  'cargo +stage1.2 build --release' ran
    1.12x faster than 'cargo +stage1 build --release'

[ogoffart]

Keep in mind that if this is happening in cargo check testcases, all you'll be seeing is how fast or slow rustc is, with LLVM not being involed at all.

If I read the number correctly, the "-check" benchmark does not seem to be impacted. The red numbers are only in the "-opt" and "-debug" benchmarks

[rust-timer]

Finished benchmarking try commit 4fe0b8e11185e30d88ba5f5060aadf25b5236ea0

[RalfJung]

Unions got fixed, I rebased this PR.

So, can we land this?

[ogoffart]

(I'm in no position to review, but i see no problem with this, and since it is required to stabilize MaybeUnitit, it'd be great to have it in as early as possible)

[SimonSapin]

@bors r+

[bors]

📌 Commit 59786b0 has been approved by SimonSapin

[bors]

⌛ Testing commit 59786b0 with merge 75d937c...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: SimonSapin
Pushing 75d937c to master...

[gnzlbg]

Finally, awesome, thanks!