-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
core/compiler_hints: add likely() / unlikely() hints #19156
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm and for assert()
it definitely is worth the additional maintenance overhead.
See two inline nitpicks
likely and unlikely will not do the same as changin the optimization level since doing that kind of reordering might enlarge the build result (but still be faster since the hotpath is shorter) |
I think likely does not provide extra information to the compiler since the |
bors merge |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since assert.h implements a standard header it should not provide defines that are not part of that standard header
http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf :7.1.3 p 112 (pdf:119) "...the Standard assures that macro and typedef names are reserved only if the associated header is explicitly included"
18472: drivers/mrf24j40: add support for IEEE 802.15.4 Radio HAL r=benpicco a=jia200x 18863: boards/esp32s2-mini: add definition for ESP32 S2 Mini r=benpicco a=benpicco 19156: core/compiler_hints: add likely() / unlikely() hints r=benpicco a=benpicco Co-authored-by: Jose Alamos <[email protected]> Co-authored-by: Benjamin Valentin <[email protected]> Co-authored-by: Benjamin Valentin <[email protected]>
Build failed (retrying...): |
bors cancel |
Canceled. |
2a64380
to
e75c702
Compare
bors merge |
👎 Rejected by PR status |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bors merge
👎 Rejected by PR status |
bors retry |
bors cancel |
👎 Rejected by PR status |
bors merge |
👎 Rejected by PR status |
bors merge --force |
👎 Rejected by PR status |
bors merge |
👎 Rejected by PR status |
bors, did you change your mind? |
👎 Rejected by PR status |
bors retry |
👎 Rejected by PR status |
bors merge |
🕐 Waiting for PR status (GitHub check) to be set, probably by CI. Bors will automatically try to run when all required PR statuses are set. |
bors merge |
bors r- |
bors cancel |
bors r+ |
🎉 So in 3h - 5h it will get merged :) |
Build succeeded: |
Contribution description
The compiler can optimize the code better if it knows whether a condition is likely taken / not taken.
This is usually something the developer should not bother with, but for things like
assert()
where the condition should always be true, we can tell the compiler to optimize that path.Testing procedure
No logic changes, CI will ensure that all our compilers know about the builtin.
Issues/PRs references
#19155 (comment)