[nickysielicki]

See also: https://blog.aaronballman.com/2020/08/dont-use-the-likely-or...

tl;dr: these attributes are absolutely full of footguns because the standard is not explicit about precedence and nesting, and you should probably avoid them and prefer to spend time investing in PGO. It’s very easy to make sane-looking code containing these attributes which does the exact opposite of what you intended.

Note that this issue does not exist with the equivalent C macros — those generally behave as expected. But you should probably just invest in PGO instead of static hints there, too.

[plorkyeran]

My experience with PGO it that it's a much larger footgun. If you can't profile your actual production workload then it's very frequently just going to make your program slower. Even if you can profile production, it's still an easy way to completely blow out your long-tail latency for codepaths that PGO decides don't matter.

[cmovq]

PGO is not a silver bullet. If you've identified a problem that can be solved by a simple static hint you should do that. I agree littering your code with likely/unlikely will probably make things worse, so it's best to save them for those exceptional cases where you know it will make an improvement.

[Kranar]

It's not a silver bullet but PGO does subsume these hints. Consider what do you do if PGO conflicts with your static hints? My hypothesis is that in that case the static hint is most likely incorrect and contributing to slower code.

So either you aren't using PGO at all, which is fine if squeezing out these kinds of optimizations isn't that important to you, but then what's the point having these static hints?

Or you are using PGO, in which case there's no point in having these static hints because PGO will identify the likely and unlikely scenarios on your behalf. If PGO doesn't identify likely and unlikely branches, then the reason is because your profile isn't representative of how your program will actually be run in production, but in that case the solution is to provide a more representative profile instead of using [[likely]] and [[unlikely]].

[secondcoming]

If someone is going to go crazy and try mark the likelihood of all paths in their code then they clearly don't understand the feature.

That doesn't mean it shouldn't exist and isn't useful.

[ReleaseCandidat]

Oh, I didn't see this before posting. Well, at least the chance is higher that somebody reads the article ;)