Pre-RFC: branch optimization for panicking paths

[ishitatsuyuki]

Summary

Provide optimizer hints as “unlikely” for panicking paths.

Motivation

Unlike exception (in other languages), panics are used for critical (logic) errors and is unlikely to be called. We can attempt to improve the performance of unwrap() with this.

---

I consider this RFC to be simple, or this maybe doesn’t need a RFC at all. Comments on improving or expanding this are welcome, as well as discussing potential issues of this RFC.

[Centril]

Would be nice with an RFC to at least discuss alternatives?

[rkruppe]

This doesn’t seem like RFC territory, since it’s a relatively small internal change that has no observable behavior aside from code quality. Furthermore, there’s nothing to build consensus about, it’s a matter of data: someone needs to implement this and show that it performs better.

[cuviper]

I was under the impression that panics use landing pads similar to C++ exceptions. If that’s the case, then they should already be completely outside of the normal control flow.

edit: Or do you mean adding “unlikely” to branches that start a panic? That seems sensible.

[sfackler]

Isn’t this already the case? https://github.com/rust-lang/rust/blob/c417ee9ae8c30ac307c58591da46cf62e91caac1/src/libcore/panicking.rs#L41

[scottmcm]

What the #[cold] that sfackler mentioned turns into in LLVM:

This attribute indicates that this function is rarely called. When computing edge weights, basic blocks post-dominated by a cold function call are also considered to be cold; and, thus, given low weight.

https://llvm.org/docs/LangRef.html#function-attributes

[ishitatsuyuki]

I have briefly tested on godbolt and seems you’re correct. Thanks for correcting me.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.