unlikely intrinsic does not work #88767
Comments
|
Rust generates the call to |
nagisa
added
the
A-LLVM
|
This probably got broken by https://reviews.llvm.org/D100213. Expect intrinsics are now lowered before SROA. |
|
The probably most reliable way to fix this would be to not use |
nikic
added
the
I-slow
|
Just to be clear, you mean this? So instead of using |
|
Yes, that's right. This is something we'd definitely need for the more elaborate attribute-based approached discussed in #26179, so it would probably make sense to switch to this approach for the intrinsic as well. |
|
This doesn't really work for the intrinsic, since the intrinsic can be used anywhere, not just in an It would be somewhat disconcerning if the intrinsic somehow "pattern-matched on the surrounding code" to do its thing. |
|
I think that the plan in #26179 is to migrate to an attribute (e.g. |
|
@RalfJung The intrinsic already only works when used directly in an |
|
Basically, this intrinsic is already "pattern-matched on the surrounding code". But this pattern matching currently happens in LLVM, and is geared towards the IR emitted by Clang rather than rustc. Moving that pattern matching into rustc would make it more robust/predictable. |
|
Fair. In the end it's semantically a no-op so I don't care quite as much, but attributes seem like the much better design for this sort of thing so I am glad to hear that that's what we are moving towards. :) |
Is that an llvm bug? I guess I'm trying to understand how this broke and what the next steps are to fix the intrinsics. This bug and the new attributes should be considered separately. |
Nilstrieb
added
the
T-compiler
|
Any progress ? |
#[cold] on match arms ### Edit This should be in T-lang. I'm not sure how I can change it. There is discussion: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Allow.20.23.5Bcold.5D.20on.20match.20and.20if.20arms ### Summary Adds the possibility to use `#[cold]` attribute on match arms to hint the optimizer that the arm is unlikely to be taken. ### Motivation These hints are sometimes thought to help branch prediction, but the effect is probably marginal. Modern CPUs don't support hints on conditional branch instructions. They either have the current branch in the BTB (branch prediction buffer), or not, in which case the branch is predicted not to be taken. These hints are, however, helpful in letting the compiler know what is the fast path, so it can be optimized at the expense of the slow path. `grep`-ing the LLVM code for BlockFrequencyInfo and BranchProbabilityInfo shows that these hints are used at many places in the optimizer. Such as: - block placement - improve locality by making the fast path compact and move everything else out of the way - inlining, loop unrolling - these optimizations can be less aggressive on the cold path therefore reducing code size - register allocation - preferably keep in registers the data needed on the fast path ### History RFC 1131 ( rust-lang#26179 ) added `likely` and `unlikely` intrinsics, which get converted to `llvm.expect.i8`. However this LLVM instruction is fragile and may get removed by some optimization passes. The problems with the intrinsics have been reported several times: rust-lang#96276 , rust-lang#96275 , rust-lang#88767 ### Other languages Clang and GCC C++ compilers provide `__builtin_expect`. Since C++20, it is also possible to use `[[likely]]` and `[[unlikely]]` attributes. Use: ``` if (__builtin_expect(condition, false)) { ... this branch is UNlikely ... } if (condition) [[likely]] { ... this branch is likely... } ``` Note that while clang provides `__builtin_expect`, it does not convert it to `llvm.expect.i8`. Instead, it looks at the surrounding code and if there is a condition, emits branch weight metadata for conditional branches. ### Design Implementing `likely`/`unlikely` type of functions properly to emit branch weights would add significant complexity to the compiler. Additionally, these functions are not easy to use with `match` arms. Replacing the functions with attributes is easier to implement and will also work with `match`. A question remains whether these attributes should be named `likely`/`unlikely` as in C++, or if we could reuse the already existing `#[cold]` attribute. `#[cold]` has the same meaning as `unlikely`, i.e., marking the slow path, but it can currently only be used on entire functions. I personally prefer `#[cold]` because it already exists in Rust and is a short word that looks better in code. It has one disadvantage though. This code: ``` if cond #[likely] { ... } ``` becomes: ``` if cond { ... } #[cold] { ... empty cold branch ... } ``` In this PR, I implemented the possibility to add `#[cold]` attribute on match arms. Use is as follows: ``` match x { #[cold] true => { ... } // the true arm is UNlikely _ => { ... } // the false arm is likely } ``` ### Limitations The implementation only works on bool, or integers with single value arm and an otherwise arm. Extending it to other types and to `if` statements should not be too difficult.
Code:
Compiler explorer
rustc 1.57.0-nightly (fdf6505 2021-09-07)
Generates assembly:
If
unlikelyworked, call toaaawould be after jump (it works ifaaais marked#[cold]for example).Unlikely is present in Rust MIR:
but it is lost in LLVM IR:
The text was updated successfully, but these errors were encountered: