On 05/15/2012 06:27 PM, Jim Rees wrote: > Boaz Harrosh wrote: > > > Normally we wouldn't put an unlikely() here. It makes the code > > less readable and it's not going to affect benchmarks. But I can > > add one if people prefer. > > > > Personally It makes it more readable for me. It's like a statement: > "error, always slow-path case here". I have brain parsers set > for these. > > Personally I don't like it. It's a hint for the compiler. Remember when > code was liberally sprinkled with "register" modifiers on local variables? > Turned out the compiler was smarter than we were, and those modifiers were > hurting performance. I'd rather let the compiler decide how to optimize. Actually the compiler cannot. This is specifying: "against all judgment I consider this path as the cold path, even if it is taken more times or generates less compact code. Remove this branch from branch prediction permanently, and never pre-fetch this path" Again for me it's a programming style programmer-to-programmer hint. And is very unlike "register". The Kernel style does use unlikely() extensively in error paths, so it's not only me. I'm not sure what the official stance is though. I agree that it's all just shop talk ;-) Thanks Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
