Meta tracking issue for branch hints (RFC 1131)

[nikomatsakis]

Tracking and meta discussion for branch and path hinting, including:

• likely/unlikely as accepted in Add an expect intrinsic rfcs#1131 (much has changed since this RFC)
• core::hint::{likely, unlikely} Tracking Issue for likely_unlikely and cold_path #136873
• core::hint::cold_path Tracking Issue for likely_unlikely and cold_path #136873
• bool::select_unpredictable Tracking Issue for bool::select_unpredictable #133962
• #[cold]:
  • #[cold] on match arms #120193

[pythonesque]

FWIW, looking through my own code, I actually think the fact that this can't apply to match variants is going to be fairly hard on idiomatic Rust (for example, it means you can't use it when matching on an Option, which is going to be extremely common since it amounts to if (likely(ptr != NULL)) in C).

[Aatch]

@pythonesque once I get this done, I plan on writing a follow-up RFC for a #[likely] attribute you can put on match arms. Since it's already possible to put attributes on arms (to support conditional compilation of them), it should be fairly easy to implement.

[Craig-Macomber]

It might be worth having an "unpredictable" option in addition to likely and unlikely. There is now something to lower it to in LLVM: http://reviews.llvm.org/D12341

[apasel422]

@Aatch Are you still working on this?

[vi]

Shall #[likely] be also on Result?

enum Result<T, E> {
   #[likely]
   Ok(T),
   Err(E)
}

I expect for most code Ok is likely and Err is unlikely. Of course, annotating if or match should override enum variant's annotation.

[Aatch]

@vi I think hinting should be only be used rarely, so it being on the type doesn't seem like a good idea. Result is a bit more general purpose than just error-handling, sot that kind of hinting would impact code where it's inappropriate. Hinting should only really be done at the site itself.

[vi]

@Aatch, Is it a good idea to have likely in every place where something is likely? Can it also serve for self-documentation: follow "likelies" and see happy path?

[Aatch]

@vi is is not. As a general rule, people are pretty bad at knowing what cases are actually likely or not. Branch hinting is a fairly specific optimisation hint, used incorrectly it can actually make code slower. It should also only really be used when the unlikely case is known to be very unlikely.

Basically, you should only use it if it makes your code faster, otherwise it should be there.

[pczarn]

@vi It might be good idea if the likely thing is cheap, and the unlikely thing is expensive. For example, Vec::push is expensive if it causes a reallocation, and very cheap otherwise.

In my opinion, frequent use of likely is either unnecessary or just manual profile-guided optimization.

[Stebalien]

Instead of arguing about it, why not just test it? Annotate Result, and then see if rustc bootstraps significantly faster. This won't give a definitive answer but will help determine if it's worth considering.

[comex]

Now that MIR is a thing, it would be nice if this were implemented.

[nikomatsakis]

@comex I do agree =)

@Aatch Not sure what your time is like, but if you don't have time to implement this, it seems like a case where we might be able to mentor someone. The idea would be to leave a comment explaining roughly how you think it should work, and then tagging the issue with E-mentor and E-help-wanted. I of course can do this too and will try to remember to do so. =)

[nikomatsakis]

Unassigning @Aatch since, empirically, he doesn't seem to be actively hacking on this right now. =) (Feel free to correct me.)

[seanmonstar]

@nikomatsakis PR up, though I could use some help adding tests.

[Aatch]

Copying @nagisa's comment from #36181:

#llvm told me expect intrinsic is more harmful than it is helpful and that the branch weight metadata should be emitted instead. Might be worth to go back and reconsider the RFC, since the branch weight metadata is more powerful and expressive and would be better expressed as attributes in source too.

why is clang > 3.6 not emiting expect intrinsic for __builtin_expect?
nagisa: it turns out that the expect intrinsic overall harmed the optimizer by inhibiting certain optimizations
so we now directly lower __builtin_expect to branch probabilities in the frontend when generating IR

I think that keeping the intrinsics is a good idea. They should be fairly obvious for people coming from C/C++. Attributes aren't mutually exclusive with the intrinsics, so we're not exactly cutting ourselves off with intrinsics.

Supporting branch weights at the MIR level would probably be the easiest implementation for lowering to the metadata ourselves.

[chriskrycho]

Just adding a note here as I'm processing everything in #38643: it will need docs before stabilization. @nikomatsakis would you mind adding a note to that effect in the root of the issue?

[nikomatsakis]

@chriskrycho done

[saethlin]

#120370 should now work, at least sometimes. I don't know if #88767 is fixed, but since reviewing the fix PR I now have the opinion that a #[cold] on arms or the intrinsics::cold_path() strategy is the right way to provide this branch hinting information.

[Clipi-12]

Proposal to reexport intrinsics::cold_path() in std::hint in libs-team#510

[tgross35]

We now have likely, unlikely and cold_path in core::hint. The feature currently points here but I think it's better to keep the library discussion separate from this issue's meta discussion (happy almost tenth birthday to this issue), so I'm moving the gates to #136873.