https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79489
--- Comment #2 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #1)
> 1) we wrongly match early return heuristics.
Ah, right, that seems like an important heuristic, but it is very eager, it
applies even if both branches lead to return in equivalent ways. Adding another
function call before return 0 is not enough to disable it, I need to add an
if... On the other hand, I guess that in a less reduced testcase, after
inlining and everything, this may not be such a common case.
> 2) We completely ignore 'n != 0' comparison as we consider it useless due to:
>
> /* Comparisons with 0 are often used for booleans and there is
> nothing useful to predict about them. */
Ah, right, I hadn't thought about this C misfeature :-( I doubt it would make
sense to look at the source language to tweak this heuristic for languages that
use a real 'bool' type... Actually, C uses int, C++ uses a prec=1 type, are
there other cases? Maybe ignoring !=0 could be limited to those 2 types, so at
least long would not be affected?
> Yep, sometimes mixture of predictors result in strange results. However we
> do not prefer
> 'else' as more likely compared to 'then' branch. It all depends on the
> predictors, e.g.
>
> some_func (int n)
> {
> <bb 2> [100.00%]:
> if (n_2(D) != 0)
> goto <bb 3>; [46.00%]
> else
> goto <bb 4>; [54.00%]
>
> is same to:
>
> <bb 2> [100.00%]:
> if (n_2(D) == 0)
> goto <bb 3>; [46.00%]
> else
> goto <bb 4>; [54.00%]
Well, in both cases the "else" branch has higher probability than the "then"
branch... But I understand your point.
Thank you for the detailed analysis, very helpful :-)
