`match` an `std::cmp::Ordering` generates less optimized code in nightly

[yume-chan]

I'm interested in this comment:

rust/library/core/src/slice/mod.rs

Lines 2204 to 2217 in 3824017

	let cmp = f(unsafe { self.get_unchecked(mid) });
	// The reason why we use if/else control flow rather than match
	// is because match reorders comparison operations, which is perf sensitive.
	// This is x86 asm for u8: https://rust.godbolt.org/z/8Y8Pra.
	if cmp == Less {
	left = mid + 1;
	} else if cmp == Greater {
	right = mid;
	} else {
	// SAFETY: same as the `get_unchecked` above
	unsafe { crate::intrinsics::assume(mid < self.len()) };
	return Ok(mid);
	}

So I did some testing:

---

The following code snippet is the "bad" one (match an std::cmp::Ordering) in above comment, but with f manually inlined.

use std::cmp::Ordering;
use std::cmp::Ordering::*;

pub fn custom_binary_search_1<'a>(slice: &'a [u8], x: &u8) -> Result<usize, usize> {
    let s = slice;
    let mut left = 0;
    let mut right = s.len();
    while left < right {
        // never overflow because `slice::len()` max is `isize::MAX`.
        let mid = (left + right) / 2;
        // SAFETY: the call is made safe by the following invariants:
        // - `mid >= 0`
        // - `mid < size`: `mid` is limited by `[left; right)` bound.
        let cmp = unsafe{ s.get_unchecked(mid).cmp(x) };
        match cmp {
            Less => left = mid + 1,
            Greater => right = mid,
            Equal => return Ok(mid),
        }
    }
    Err(left)
}

---

In version 1.53.0-beta.12 (2021-06-12 e7a67cc), release mode, it generates the following x86 assembly (related parts only):

        jmp	.LBB0_3
.LBB0_7:
	add	rdx, 1                     # mid += 1
	mov	rcx, rdx                   # left = mid
	cmp	rcx, rsi                   # while left < right
	jae	.LBB0_9                    # (end loop)
.LBB0_3:
	lea	rdx, [rcx + rsi]           # mid = left + right
	shr	rdx                        # mid /= 2
	cmp	byte ptr [rdi + rdx], r8b  # match s[mid].cmp(x)
	jb	.LBB0_7                    # Less => ...
	je	.LBB0_6                    # Equal => ...
	mov	rsi, rdx                   # Greater => right = mid
	cmp	rcx, rsi                   # while left < right
	jb	.LBB0_3                    # (continue loop)
.LBB0_6:
	xor	eax, eax                   # return (0, mid)
	ret

(Which is identical to manually expanding to if..else if..else, however it's not the point of this issue)

---

In version 1.55.0-nightly (2021-06-20 e82b650), release mode, the generated assembly code is:

	mov	r9, -1                       # constant of std::cmp::Ordering::Less
	jmp	.LBB0_3

.LBB0_5:                                #   in Loop: Header=BB0_3 Depth=1
	mov	rcx, rdx                     # left = mid         
	add	rcx, 1                       # left += 1
	mov	rdx, rsi                     # temp = right

.LBB0_6:                                #   in Loop: Header=BB0_3 Depth=1
	mov	rsi, rdx                     # right = mid
	cmp	rcx, rdx                     # while left < right
	jae	.LBB0_7                      # (end loop)

.LBB0_3:                                # =>This Inner Loop Header: Depth=1
	lea	rdx, [rcx + rsi]             # mid = left + right
	shr	rdx                          # mid /= 2
	xor	eax, eax                     # cmp = 0
	cmp	byte ptr [rdi + rdx], r8b
	setne	al                           # cmp = s[mid] == x ? 0 : 1
	cmovb	rax, r9                      # cmp = s[mid] < x ? -1 : temp
	cmp	rax, -1                      # if cmp == Less
	je	.LBB0_5                      # Less => ...
# %bb.4:                                #   in Loop: Header=BB0_3 Depth=1
	cmp	rax, 1                       # if cmp == Greater
	je	.LBB0_6                      # Greater => ...
# %bb.9:
	ret

It's same as the "bad" result in original comment, and obviously much unoptimized.

I think match an Ordering should be a quite common use case, so shouldn't be deoptimized.

---

Version it worked on

Rust Playground: 1.53.0

Rust Playground: 1.53.0-beta.12 (2021-06-12 e7a67cc)

Version with regression

a55748f

[fee1-dead]

See also #86391 and #86354.

[apiraino]

thanks @yume-chan for debugging

paging @Aaron1011 @michaelwoerister as perhaps can share insights about #85702 - is the PR relevant to this issue and the mentioned ones (#86391, #86354)? Do we have a common root cause? Perhaps this one is a duplicate? thanks :-)

[pnkfelix]

(I find it hard to believe that #85702 is in any way truly related to the problem described here.)

---

Update: What I can believe is that the bisection from the description is only at the granularity of nightlies, not individual PR's. @yume-chan, is that correct? (I.e., is it true that the bisection you performed only went to the level of nightlies, not the finer grain of individual PR's?)

((cargo-bisect-rustc can help with traversing the finer-grain space of individual PR's, FYI.))

[yume-chan]

@pnkfelix Yes, I didn't bisect exact version. My versions are taken from Compiler Explorer and Rust Playgournd.

Thanks for pointing to cargo-bisect-rustc, the results are

searched nightlies: from nightly-2021-05-17 to nightly-2021-05-18
regressed nightly: nightly-2021-05-18
searched commits: from fe72845 to 3e99439
regressed commit: a55748f

bisected with cargo-bisect-rustc v0.6.0

Host triple: x86_64-pc-windows-msvc
Reproduce with:

cargo bisect-rustc --test-dir=rust-lib --start=2021-05-17 --end=2021-05-18 --preserve

[michaelwoerister]

@apiraino I don't think #85702 can be relevant for this issue.

[pnkfelix]

Okay, so the subsequent bisection claims that PR #84993 is the injection point.