Tracking Issue for bool::select_unpredictable

[joboet]

Feature gate: #![feature(select_unpredictable)]

This is a tracking issue for bool::select_unpredictable, which selects between two values and hints to the optimizer that it should try to generate branchless code.

Public API

impl bool {
    /// Returns either `true_val` or `false_val` depending on the value of
    /// `condition`, with a hint to the compiler that `condition` is unlikely
    /// to be correctly predicted by a CPU’s branch predictor.
    pub fn select_unpredictable<T>(self, true_val: T, false_val: T) -> T;
}

Steps / History

• ACP: ACP: add bool::select libs-team#468
• Implementation: core: implement bool::select_unpredictable #133964
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• This should be const, right?

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[tgross35]

Reading through the ACP it seems like the justification for having this on bool, rather than hint or as an attribute, is that it it acts as a way to emulate ternaries in Rust for convenience/codestyle. Tying this to a low level optimization feature feels quite weird, as well as potentially confusing to users who see this in the API docs without a good equivalent.

If there is objection to hint::unpredictable(bool) then I think we should consider also adding @scottmcm's suggestion of a regular select method.

(sorry for the nonsensical email, accidentally submitted before I was done writing)

[leb-kuchen]

I would prefer a builtin branch_hint function as the first statement in a branch like in Zig.
BrachHInt
branch_hint()
This would a lot more flexible and not only work with a ternary statement.

[hanna-kruppe]

For likely/unlikely, such intrinsic(s) are under discussion at rust-lang/libs-team#510. In contrast, the motivation for select_unpredictable is to reliably get branchless machine code. Expressing that by control flow at the source level can sabotage the intended effect, as discussed in the APC. So an equivalent of Zig's branch_hint(.unpredictable) wouldn't be a good replacement for select_unpredictable. If it's still useful for other reasons, then that should be an additional proposal laying out those reasons.

[Amanieu]

I'm personally inclined to move this to std::hint to make it clear that it is only an optimization hint and not something that is guaranteed (e.g. for cryptographic code). It would slightly depart from the precedent that all existing functions in std::hint are no-ops, but I don't think this is a significant concern.

[hanna-kruppe]

This is a good point. It would also be inconsistent with a "non-unpredictable" select method (as discussed in the ACP) which has no reason at all to live in std::hint. But perhaps the important thing is just that both exist and not where they live and how they're invoked (cond.select(t, f) vs hint::select_unpredictable(cond, t, f)).