Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think it is used for code layout: typically you want to make the most often taken branch as fallthrough as it can be slightly faster even when perfectly predicted.

I also tried (and failed) to use expect with probability to generate a cmov, but in retrospect it is obvious: the parameter is not the prediction probability, but the taken/not-taken probability, and even a branch that goes either way with 50% probability can still be predicted perfectly (for example a branch that switches every other iteration), so the parameter can't be used to decide between predication and prediction.

edit: what we really need is an [[unpredictable]] attribute.



Indeed: A branch taken 50% of the time can be readily predicted 100% of the time if it follows a pattern the CPU can infer.

Why you have to be careful choosing realistic input data if you are microbenchmarking at this level for a real purpose.



Which also does not affect cmov conversion. Every time this comes up I bring up this long-standing LLVM bug: https://bugs.llvm.org/show_bug.cgi?id=40027


__builtin_unpredictable is gonna be fixed in LLVM/clang 17: https://github.com/llvm/llvm-project/commit/09515f2c20111628...

(also, bugs.llvm.org is old; the more up-to-date (but still open) issue is https://github.com/llvm/llvm-project/issues/39374)


Amazing, finally!!!


>typically you want to make the most often taken branch as fallthrough as it can be slightly faster even when perfectly predicted.

Sure, but that application doesn't require a fine-grained probability estimate.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: