Skip to content

Meta tracking issue for branch hints (RFC 1131) #26179

Closed
#151576
Closed
Meta tracking issue for branch hints (RFC 1131)#26179
#151576
Labels
A-intrinsicsArea: IntrinsicsB-RFC-approvedBlocker: Approved by a merged RFC but not yet implemented.B-unstableBlocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCE-help-wantedCall for participation: Help is requested to fix this issue.S-tracking-perma-unstableStatus: The feature will stay unstable indefinitely.T-langRelevant to the language teammetabugIssues about issues themselves ("bugs about bugs")

Description

@nikomatsakis
nikomatsakis
opened on Jun 10, 2015

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

Activity

  1. nikomatsakis
    added
    metabugIssues about issues themselves ("bugs about bugs")
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    on Jun 10, 2015
  2. Aatch
    self-assigned this
    on Jun 15, 2015

  3. pythonesque commented on Jun 16, 2015

    @pythonesque
    pythonesque
    on Jun 16, 2015
    Contributor

    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).

  4. Aatch commented on Jun 17, 2015

    @Aatch
    Aatch
    on Jun 17, 2015
    Contributor

    @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.

  5. Craig-Macomber commented on Sep 25, 2015

    @Craig-Macomber
    Craig-Macomber
    on Sep 25, 2015
    Contributor

    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

  6. apasel422 commented on Nov 9, 2015

    @apasel422
    apasel422
    on Nov 9, 2015
    Contributor

    @Aatch Are you still working on this?

  7. vi commented on Mar 28, 2016

    @vi
    vi
    on Mar 28, 2016
    Contributor

    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.

  8. Aatch commented on Mar 29, 2016

    @Aatch
    Aatch
    on Mar 29, 2016
    Contributor

    @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.

  9. vi commented on Mar 29, 2016

    @vi
    vi
    on Mar 29, 2016
    Contributor

    @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?

  10. Aatch commented on Mar 30, 2016

    @Aatch
    Aatch
    on Mar 30, 2016
    Contributor

    @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.

  11. pczarn commented on Mar 30, 2016

    @pczarn
    pczarn
    on Mar 30, 2016
    Contributor

    @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.

  12. Stebalien commented on Mar 30, 2016

    @Stebalien
    Stebalien
    on Mar 30, 2016
    Contributor

    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.

  13. comex commented on Aug 20, 2016

    @comex
    comex
    on Aug 20, 2016
    Contributor

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

  14. nikomatsakis commented on Aug 31, 2016

    @nikomatsakis
    nikomatsakis
    on Aug 31, 2016
    ContributorAuthor

    @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. =)

  15. 115 remaining items

  16. github-actions
    added 8 commits that reference this issue on Mar 6, 2025

    Change the issue number for `likely_unlikely` and `cold_path`

    b997811

    Change the issue number for `likely_unlikely` and `cold_path`

    8eabdc5

    Rollup merge of rust-lang#133695 - x17jiri:hint_likely, r=Amanieu

    9072ebd

    Change the issue number for `likely_unlikely` and `cold_path`

    1c3f188

    Rollup merge of rust-lang#136874 - tgross35:likely-unlikely-tracking,…

    4322eca

    Change the issue number for `likely_unlikely` and `cold_path`

    928bef9

    Rollup merge of rust-lang#136874 - tgross35:likely-unlikely-tracking,…

    64453dd

    Change the issue number for `likely_unlikely` and `cold_path`

    d4c4c56
  17. christian-schilling
    added 2 commits that reference this issue on Jan 27, 2026

    Auto merge of #120370 - x17jiri:likely_unlikely_fix, r=saethlin

    2dd2dd2

    Auto merge of #120370 - x17jiri:likely_unlikely_fix, r=saethlin

    73ae407
  18. jhpratt
    added a commit that references this issue on Feb 7, 2026

    Rollup merge of rust-lang#151576 - tgross35:stabilize-cold-path, r=jh…

    893d205
  19. JonathanBrouwer
    added 2 commits that reference this issue on Feb 7, 2026

    Rollup merge of rust-lang#151576 - tgross35:stabilize-cold-path, r=jh…

    330a7f3

    Rollup merge of rust-lang#151576 - tgross35:stabilize-cold-path, r=jh…

    27d6b3c
  20. rust-bors
    closed this as completedin 27d6b3con Feb 7, 2026
  21. rust-timer
    added a commit that references this issue on Feb 7, 2026

    Unrolled build for #151576

    60ef377
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-intrinsicsArea: IntrinsicsB-RFC-approvedBlocker: Approved by a merged RFC but not yet implemented.B-unstableBlocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCE-help-wantedCall for participation: Help is requested to fix this issue.S-tracking-perma-unstableStatus: The feature will stay unstable indefinitely.T-langRelevant to the language teammetabugIssues about issues themselves ("bugs about bugs")

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions