likely()/unlikely() macros in the Linux kernel with a segmentation fault

1
votes

I have an understanding of how the likely()/unlikely() macros work and I also have an understanding of branch prediction. Unfortunately, I did not learn branch prediction in the context of high level programming.

What I want to know is if the evaluation within the likely/unlikely macro results in a segmentation fault, how does that impact the branch prediction history or even the current outcome/pipeline.

I fail to understand that if the validation of the prediction didn't complete, how do we know if it was a success or a failure ?

1
cgccx86branch-predictionlikely-unlikely
I think the start of the this question distracts from what you're really asking, because you want to know how branch prediction works in the case that a speculatively executed branch gets flushed, right? – harold
Not really. The decision to whether or not to flush the would depend on the evaluation, isn't that correct ? My question was what if the evaluation couldn't be completed. What is the state of the system in that case ? – user3224083
Yes that's what I meant. If the entire branch has the be flushed, not just code after it. It's not at all related to likely/unlikely, and not even really to exceptions either (you could just corrupt the predictors, an exception is so expensive that taking a hit to bp accuracy doesn't matter) - when this really matters is when you're speculating past several branches and you mispredict the first one. There are several solutions for that. – harold

1 Answers

4
votes

__builtin_expect (used in the definition of the likely/unlikely macros) doesn't generate actual code to evaluate either of its arguments. All it does is tell the compiler what result to expect if it were evaluated.

It might confuse the optimizer if you tell it that *(int*)NULL is usually 13, but (barring compiler bugs) it won't segfault the compiler, or produce code which segfaults at run-time.

Another answer on the old question has actual asm with/without the macro, showing that their effect is in how gcc lays out the code (e.g. putting the unlikely case off by itself, and the likely case in the fall-through not-taken side of a conditional branch where instruction-cache misses are less likely).

This isn't quite a duplicate of likely()/unlikely() macros in the Linux kernel - how do they work? What's their benefit?, but you will find much more info about how these macros work and what their effect is on that Q&A.