Messages in this thread | | | Date | Tue, 21 Feb 2012 16:16:17 -0500 | From | Mathieu Desnoyers <> | Subject | Re: [PATCH 00/10] jump label: introduce very_[un]likely + cleanups + docs |
| |
* H. Peter Anvin (hpa@zytor.com) wrote: > On 02/21/2012 12:39 PM, Steven Rostedt wrote: > > On Tue, 2012-02-21 at 15:20 -0500, Jason Baron wrote: > > > >> I'm not really too hung up on the naming, but I did think that > >> very_[un]likely were an interesting possibility. > > > > The problem comes from what Peter said. They are too similar to > > "likely()" and "unlikely()", and can become confusing. > > > > Maybe "static_likely()" and "static_unlikely()" as the word "static" can > > imply something strange about these. Or perhaps a "const_likely()"? > > > > Maybe "dynamic_branch_true()" and "dynamic_branch_false()". This may be > > the most descriptive. > > > > I thought about this some more, and the very_[un]likely() naming is even > worse than I originally thought: the jump label stuff isn't about the > bias level, but rather if a static decision (on the order or once per > boot) can be made to go one way or the other. > > -hpa
I agree that this decision is taken typically once at boot time, so claiming it is only a strong compiler bias hint for block placement would be a lie. However, I think the fact that the fall-through is for either true or false branch seems to be an implicit bias. Therefore, I start to like the static_likely()/static_unlikely(), which conveys both the static nature of the branch, as well as the bias.
Thanks,
Mathieu
-- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com
| |