Pre-RFC: Stabilization of `likely(bool)`, `unlikely(bool)` & `assume(bool)` intrinsics

[CAD97]

@alonely0

This not only would require the experimental attributes on expressions feature, but also attributes on statements.

Applying outer attributes to let statements is already stable, as are outer attributes on expression statements, expressions in comma separated lists, and block tail expressions, so long as the annotated expressions are not binops or ranges.

Macro statements don't take outer arguments per the reference grammar, but rustc still accepts it. Item statements obviously accept outer attributes.

@alonely0

we've already struggled enough (and still struggling) with attributes on expressions, I don't even want to think about the heavy-lifting necessary for bringing that to statements. This applies even if we're just allowing them for if let & let-else statements.

The main struggle with attributes on expressions is actually specifically when they're ambiguous with a statement attribute. It's fairly simple to say that attributes on expressions bind tighter than binary operators, so #[a] b + #[c] d is (#[a] {b}) + (#[c] {d}), not #[a] {b + #[c] {d}}, but this is less clear when you have a statement expression, e.g.

#[a]
b + d;

Barring that example, the choice of how tightly outer attributes bind is still an arbitrary choice, but it's a choice that's easier to make.

@alonely0

adding an attribute to a let outside of hinting a branch seems nonsense to me. Let doesn't even produce a value in the first place!

Marking an irrefutable let as likely/unlikely obviously doesn't make sense. Marking a refutable let, however, does make sense; you're hinting as to whether the refutable pattern match is successful.

@alonely0

perhaps because I just want this to get stabilized ASAP, and we're instead rambling about hardly possible, if at all, grammar & language design changes

Rust has a track record, for better or for worse, of refusing to stabilize the "simple, works, but potentially suboptimal" choice when a potentially better design is known to exist.

@alonely0

Regarding the actual problem, hinting if let and let-else branches, this is easily solved by doing something like this before the branch (tweak it to your use-case):

likely(foo.is_some());

This was specifically called out as not working above:

@cg909

If likely, unlikely and unpredictable were provided as functions, e.g. directly affecting an if let would be impossible:

let _ = likely(foo.is_some()); // most certainly has no effect for the `if let` below

[because] the LLVM intrinsic llvm.expect, which is used to implement likely, only influences edge weight metadata on dependent branches and is a no-op if no branching directly depends on it

so asserting that

@alonely0

The optimizer will register the weight changes / PGO for the status of the variable, discard the branch because its results are unused and it has no side effects, and compute the following branches (the if let / let-else) with the new weights / PGO.

is false for existing backends. The issue is that you end up with low-level code that looks something like

let foo: Option<&T>;

// likely(foo.is_some());
let _1: usize = transmute_copy(&foo);
let _2: bool = _1 != 0;
likely(_2);

// if let Some(bar) = foo
let _3: usize = transmute_copy(&foo);
let _4: bool = _3 != 0;
if _4 {
    let bar: &T = transmute_copy(&foo);

    // todo!()
}

and if the optimizer is going to "propagate the weight changes for the variable", then it needs to reverse the computation of the test boolean if it wants to derive information about the shared variable which is actually used to derive the later branch.

Your scheme might work for likely(b); if b { /* ... */ }, since the same variable is used both in the hint and in the branch. But using a non-place expression in the hint is basically never going to work.

@alonely0

it feels so elegant and low-level, yet so simple

On the contrary, likely(foo.is_some()); is frighteningly high-level for the optimizer, since you're deriving a single boolean from a larger state and saying "hey this is likely" then throwing that boolean away and deriving a new boolean which could be related, but it might not be, the optimizer needs to derive that somehow, and you've derived the new test in a different manner. This is a nightmare to resolve and turn into something useful for the optimizer. Where on the other hand, taking specific branching operations (e.g. an if or a fallible pattern match in let/match) and hinting the relative likelihood of the branches is much more directly meaningful to the optimizer.