[incremental] Specialize encoding and decoding of Fingerprints

[wesleywiser]

This saves the storage space used by about 32 bits per Fingerprint.
On average, this reduces the size of the /target/{mode}/incremental
folder by roughly 5% Full details here.

Fixes #45875

r? @michaelwoerister

[michaelwoerister]

Thanks a lot, @wesleywiser! This looks very good. Looking forward to seeing if it also has an impact on compile times.

I added some comments below: The encoding still has to be made platform-indepedent but that should be easy to implement.

[michaelwoerister]

Since we are emitting raw bytes here we can't rely on leb128 to take care integer endianess, so we have to do it ourselves. Fortunately that should be straightforward. Just write the following here:

let bytes: [u8; 16] = unsafe { mem::transmute((self.0.to_le(), self.1.to_le())) };

and...

[michaelwoerister]

... the following here:

Ok(Fingerprint(u64::from_le(l), u64::from_le(r)))

(If you get a method resolution error, you might have to use std::u64;)

[wesleywiser]

@michaelwoerister fixed

[michaelwoerister]

Thanks, @wesleywiser! Looks great now.

@eddyb, do you know if rustc could potentially re-order the fields of the tuple in memory and cause the transmute to be problematic here:
https://github.com/rust-lang/rust/pull/47243/files#diff-4041379a1583f33e58f7f2cd2aafc80aR53

Or are tuples always #[repr(C)]?

[eddyb]

@michaelwoerister They're not #[repr(C)], use an array or a #[repr(C)] struct instead.

[michaelwoerister]

Thanks for the quick reply, @eddyb!

@wesleywiser, the following should avoid running into memory layout problems:

...
// When encoding
let bytes: [u8; 16] = unsafe { mem::transmute([self.0.to_le(), self.1.to_le()]) };
...
// When decoding (slices cannot be destructured unfortunately).
let fingerprint: [u64; 2] = unsafe { mem::transmute(bytes) };
Ok(Fingerprint(u64::from_le(fingerprint[0]), u64::from_le(fingerprint[1])))

[eddyb]

slices cannot be destructured unfortunately

You can do let [a, b]: [u64; 2] - you're in the compiler, it's just a feature gate away.

[michaelwoerister]

The #![feature(slice_patterns)] is already enabled for this crate, so you can use destructuring as @eddyb suggests.

[wesleywiser]

Fixed

[michaelwoerister]

Awesome, thank you!

@bors r+

[bors]

📌 Commit 01c890e has been approved by michaelwoerister

[kennytm]

@bors p=15

Just moving everything which may improve performance up 😭

[bors]

⌛ Testing commit 01c890e with merge c9c2980...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: michaelwoerister
Pushing c9c2980 to master...