Add select_unpredictable to force LLVM to use CMOV

[Amanieu]

Since https://reviews.llvm.org/D118118, LLVM will no longer turn CMOVs into branches if it comes from a select marked with an unpredictable metadata attribute.

This PR introduces core::intrinsics::select_unpredictable which emits such a select and uses it in the implementation of binary_search_by.

[rustbot]

r? @joboet

rustbot has assigned @joboet.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[Amanieu]

r? compiler

[klensy]

Can title mention new intrinsic? This way it's easier to find new things.

[nikic]

We should not perform aggregate loads. I think what you want to do here is something like OperandValue::Ref(ptr).store(self, result), which lowers to a memcpy.

[Amanieu]

I've updated it to do that. I'm still not entirely sure if it's doing the right thing, but at least it does the same thing as black_box now.

[petrochenkov]

r? @nikic

[nikic]

@bors r+ rollup=never

[bors]

📌 Commit 4f78f9f has been approved by nikic

It is now in the queue for this repository.

[DianQK]

Maybe?

Suggested change

	core::intrinsics::select_unpredictable(p, a, b)
	core::intrinsics::select_unpredictable(p, a, b)
	// CHECK-NOT: select i1
	// CHECK: ret void

Otherwise, I don't know what we are supposed to be testing.

[bors]

⌛ Testing commit 4f78f9f with merge 710ce90...

[bors]

☀️ Test successful - checks-actions
Approved by: nikic
Pushing 710ce90 to master...

[rust-timer]

Finished benchmarking commit (710ce90): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.3%	[0.2%, 0.5%]	5
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 0.6%)

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.6%	[0.6%, 0.6%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.6%	[0.6%, 0.6%]	1

Cycles

Results (secondary 2.7%)

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.7%	[2.2%, 3.1%]	5
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 770.597s -> 771.833s (0.16%)
Artifact size: 331.91 MiB -> 331.86 MiB (-0.02%)

[gendx]

This looks like a great intrinsic, that on paper could be applicable to a variety of domains (e.g. cryptography, as it corresponds to what crates like subtle or cmov attempt to do). However, I'm wondering what guarantees it really offers in terms of "forcing LLVM to use CMOV"?

I've tried the following simple functions, and it seems that although the unpredictable annotation is indeed present in the IR, LLVM optimizes away most operations (except the trivial standalone select_unpredictable): https://godbolt.org/z/GbE71z3dd

Is it intended? And if so, in which contexts is this intrinsic applicable?

#![feature(core_intrinsics)]

use std::intrinsics::select_unpredictable;

#[no_mangle]
pub fn baseline(p: bool, x: i32, y: i32) -> i32 {
    select_unpredictable(p, x, y)
}

#[no_mangle]
pub fn foo(x: i32, y: i32) -> i32 {
    select_unpredictable(false, x, y)
}

#[no_mangle]
pub fn bar(x: i32, y: i32) -> i32 {
    select_unpredictable(true, x, y)
}

#[no_mangle]
pub fn add(p: bool, x: i32, y: i32) -> i32 {
    select_unpredictable(p, x, y) + select_unpredictable(!p, x, y)
}

LLVM IR: only the baseline isn't optimized:

define noundef i32 @baseline(i1 noundef zeroext %p, i32 noundef %x, i32 noundef %y) unnamed_addr {
start:
  %0 = select i1 %p, i32 %x, i32 %y, !unpredictable !11
  ret i32 %0
}

define noundef i32 @foo(i32 noundef %x, i32 noundef returned %y) unnamed_addr {
start:
  ret i32 %y
}

define noundef i32 @bar(i32 noundef returned %x, i32 noundef %y) unnamed_addr {
start:
  ret i32 %x
}

define noundef i32 @add(i1 noundef zeroext %p, i32 noundef %x, i32 noundef %y) unnamed_addr {
start:
  %_0 = add i32 %y, %x
  ret i32 %_0
}

[nikic]

@gendx This intrinsic is a pure optimization hint. It does not carry any guarantees and is unsuitable for cryptographic use.

Is it intended? And if so, in which contexts is this intrinsic applicable?

As the name and description suggests: If the condition is unpredictable, and introducing a branch on it would degrade performance.

[RalfJung]

Please ping @rust-lang/miri when using this attribute, so that we can have a look at the spec. :)