https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116191
--- Comment #3 from ilija.tovilo <ilija.tovilo at me dot com> ---
(In reply to Andi Kleen from comment #2)
> I suppose it depends on the programing style if it's a good idea. Sometimes
> inlining allows to constant propagate and collapse a lot of code, and you
> definitely want that for cold code too.
Right, I agree. __builtin_expect() is often misused, including in our codebase.
I do think there is some probability threshold where inlining is hurtful. It
seems like gcc already uses this rationale in some cases. For example:
void unlikely_branch_through_cold_func_call(zend_string *s, bool cond) {
if (cond) {
zend_string_release(s);
cold_func();
}
printf("Hello world");
}
Here, zend_string_release() is not inlined, because the branch is considered
unlikely due to the cold_func() call. Removing the cold attribute from
cold_func() causes zend_string_release() to be inlined
(https://godbolt.org/z/rbxdsoq9n).
How exactly the branch probability should be integrated in inlining heuristics,
I don't know. But gcc not paying attention to branching probability at all does
seem a bit surprising.
