Enable Vec's calloc optimization for Option<NonZero>

[scottmcm]

Someone on discord noticed that vec![None::<NonZeroU32>; N] wasn't getting the optimization, so here's a PR 🙃

We can certainly do this in the standard library because we know for sure this is ok, but I think it's also a necessary consequence of documented guarantees like those in https://doc.rust-lang.org/std/option/#representation and https://doc.rust-lang.org/core/num/struct.NonZeroU32.html

It feels weird to do this without adding a test, but I wasn't sure where that would belong. Is it worth adding codegen tests for these?

[rust-highfive]

r? @kennytm

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

[m-ou-se]

This looks fine to me. It just makes me wonder if there's a better way we could do this for all types. Some kind of std::mem::is_just_zero_bits<T>(_: &T) -> bool with some magic implementation.

@bors r+

[bors]

📌 Commit 04d34a9 has been approved by m-ou-se

[bors]

⌛ Testing commit 04d34a9 with merge ea78d1e...

[bors]

☀️ Test successful - checks-actions
Approved by: m-ou-se
Pushing ea78d1e to master...

[proudmuslim-dev]

Shouldn't this be "makes it ub"?

Edit: I see this was already merged, I assume I was wrong

[m-ou-se]

Oh, you're right. Feel free to send a PR if you want ^^'. But this doesn't appear in any public documentation/interface, so it doesn't matter that much.

[scottmcm]

@m-ou-se I guess it depends on how much this wants to care about types with padding. Supporting (0_u8, 0_u16) would be hard, but adding an intrinsic for may_have_padding and just checking it for things that are known to definitely not have padding would be easy enough. (And the safe-transmute project might already be working on compiler code for that kind of check.)

[klensy]

https://perf.rust-lang.org/compare.html?start=8d1e3d3b74fa80ce14af6ec143f061897684582b&end=ea78d1edf364dd3a4b5ff430f76e2bdd3a713a45&stat=instructions%3Au

Very strange spike (https://perf.rust-lang.org/index.html), perhaps problems with perf runner?

[scottmcm]

Wow, very weird spike!

Definitely revert this if it's causing that much of a check build regression, but I'm a bit skeptical this it could be that big of a problem. The PR where it drops back down again also don't look like it could have improved things that much. So maybe a runner hiccup.

[Mark-Simulacrum]

Yeah, this was a runner hiccup I believe.

[klensy]

Yeah, this was a runner hiccup I believe.

Is there any logs, as part of benches isn't run at all (or not saved info about it, check lower part of bench list)?

[Mark-Simulacrum]

There's some discussion on the rustc-perf repository, but there's really no need to investigate further in my opinion.

[m-ou-se]

I guess it depends on how much this wants to care about types with padding. Supporting (0_u8, 0_u16) would be hard, but adding an intrinsic for may_have_padding and just checking it for things that are known to definitely not have padding would be easy enough. (And the safe-transmute project might already be working on compiler code for that kind of check.)

Ideally, it should work for things with padding too. As long as an all-zero-bits value is an identical value, ignoring padding bits, it shoud return true. So a (0u8, 0u16) passed in with raw bytes 00 ff 00 00 should still return true because it's identical to 00 00 00 00, so 'calloc' can be used. No clue what it'd take to implement such an intrinsic, though.