Optimize insertion sort

[ghost]

This change slightly changes the main iteration loop so that LLVM can optimize it more efficiently.

Benchmark:

name before ns/iter after ns/iter diff ns/iter diff %
slice::sort_unstable_small_ascending 39 (2051 MB/s) 38 (2105 MB/s) -1 -2.56%
slice::sort_unstable_small_big_random 579 (2210 MB/s) 575 (2226 MB/s) -4 -0.69%
slice::sort_unstable_small_descending 80 (1000 MB/s) 70 (1142 MB/s) -10 -12.50%
slice::sort_unstable_small_random 396 (202 MB/s) 386 -10 -2.53%

The benchmark is not a fluke. I can see that performance on small_descending is consistently better after this change. I'm not 100% sure why this makes things faster, but my guess would be that v.len()+1 to the compiler looks like it could in theory overflow.

[rust-highfive]

r? @aturon

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

[ghost]

r? @alexcrichton

[alexcrichton]

@bors: r+

[bors]

📌 Commit 2c816f7 has been approved by alexcrichton

[nagisa]

Since this is internal to libstd/core, could you check whether the inclusive range syntax makes things better as well?

i.e. 2 ... v.len()

[ghost]

@nagisa Inclusive range syntax makes performance slightly worse, actually...

With the old insertion sort and with inclusive range syntax there's a bound check at the beginning of insertion sort. This PR removes the bound check.

If you want to play with this, here's a playpen link.

[bors]

⌛ Testing commit 2c816f7 with merge 04e47d7...

[arielb1]

• try to fix the build on emscripten #40821
  @bors retry