Optimizing the rest of bool's Ord implementation

[danflapjax]

After coming across issue #66780, I realized that the other functions provided by Ord (min, max, and clamp) were similarly inefficient for bool. This change provides implementations for them in terms of boolean operators, resulting in much simpler assembly and faster code.
Fixes issue #114653

Comparison on Godbolt

max assembly before:

example::max:
        mov     eax, edi
        mov     ecx, eax
        neg     cl
        mov     edx, esi
        not     dl
        cmp     dl, cl
        cmove   eax, esi
        ret

max assembly after:

example::max:
        mov     eax, edi
        or      eax, esi
        ret

clamp assembly before:

example::clamp:
        mov     eax, esi
        sub     al, dl
        inc     al
        cmp     al, 2
        jae     .LBB1_1
        mov     eax, edi
        sub     al, sil
        movzx   ecx, dil
        sub     dil, dl
        cmp     dil, 1
        movzx   edx, dl
        cmovne  edx, ecx
        cmp     al, -1
        movzx   eax, sil
        cmovne  eax, edx
        ret
.LBB1_1:
        ; identical assert! code

clamp assembly after:

example::clamp:
        test    edx, edx
        jne     .LBB1_2
        test    sil, sil
        jne     .LBB1_3
.LBB1_2:
        or      dil, sil
        and     dil, dl
        mov     eax, edi
        ret
.LBB1_3:
        ; identical assert! code

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @cuviper (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[danflapjax]

Haha, I actually found this over two weeks ago and just got around to implementing it, but it looks like somebody else came across it in the meantime too: #114653 #114695

[cuviper]

I'm not sure whether the perf run will exercise this, but let's see:
@bors try @rust-timer queue

[bors]

⌛ Trying commit b75351e with merge 8104587bead96343e80021e6a1277aba1825b518...

[cuviper]

example::clamp:
        test    edx, edx
        jne     .LBB1_2
        test    sil, sil
        jne     .LBB1_3
.LBB1_2:
        or      dil, sil
        and     dil, dl
        mov     eax, edi
        ret

FWIW, cg-gcc improves the assertion to a single branch:

example::clamp:
        cmp     dl, sil
        jb      .L6
        or      esi, edi
        mov     eax, esi
        and     eax, edx
        ret
example::clamp.cold:
.L6:
        ; panic code...

[bors]

☀️ Try build successful - checks-actions
Build commit: 8104587bead96343e80021e6a1277aba1825b518 (8104587bead96343e80021e6a1277aba1825b518)

[rust-timer]

Finished benchmarking commit (8104587bead96343e80021e6a1277aba1825b518): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.0%	[2.0%, 2.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.4%	[-4.4%, -4.4%]	1
All ❌✅ (primary)	-	-	0

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 631.671s -> 631.905s (0.04%)

[scottmcm]

Ah, right, like #105840 found out, LLVM is really bad at understanding the subtraction-Ord::cmp, so it's really good for full cmp but really bad for downstream optimization of anything else 😞

[cuviper]

cg-gcc improves the assertion to a single branch

This difference is also visible in C: https://godbolt.org/z/WcWvx1rYM

Anyway, the Rust codegen is still an improvement, and being neutral on rust-timer is fine, just apparently unused.

@bors r+ rollup

[bors]

📌 Commit b75351e has been approved by cuviper

It is now in the queue for this repository.