https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79489
--- Comment #3 from Jan Hubicka <hubicka at ucw dot cz> ---
> 1) we wrongly match early return heuristics. It's a known issue as mentioned
> in
> predict.def:
>
> /* Branch causing function to terminate is probably not taken.
> FIXME: early return currently predicts code:
> int foo (int a)
> {
> if (a)
> bar();
> else
> bar2();
> }
> even though there is no return statement involved. We probably want to
> track
> this from FE or retire the predictor. */
> DEF_PREDICTOR (PRED_TREE_EARLY_RETURN, "early return (on trees)", HITRATE
> (54),
> 0)
True, the problem here is that we used to have multiple return statements in
the gimple
bodies and then it was possible to match what is first one. Now we merge them
into single
return statement and lose information about original placement. I think we
could
keep there predict_stmts to handle the info.
This can be done by FE or by gimplifier.
>
> 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. */
> else if (integer_zerop (op0)
> || integer_zerop (op1))
> ;
I think it is reasonable thing to do. You can try to invent new PRED_NONZERO
heuristics and see what hitrate it is. I remember I did it long time ago and
it did not seem to be very useful. Perhaps things has changed.
Perhaps we can get bit smarter and recognize boolean comparsions. Consider:
t(int a, int b)
{
if (a==7||b==1)
test();
}
which is seen by predict.c as:
_3 = a_2(D) == 7;
_5 = b_4(D) == 1;
_6 = _3 | _5;
if (_6 != 0)
goto <bb 3>;
else
goto <bb 4>;
so predict.c does not really see that there are two independent conditions and
interpret it as comparsion of _6 being non-zero. We could easily look into
cases comparsion operator is SSA name which is a result of boolean operation
and behave smarter. It would make sense to predict independently the value of
_3 and _5 and combine it. For that we however would need to have
infrastructure for predictions on values and then combine them same way as
predictions on edges.
This would be also more systematic way of handling builtin_expect.
Honza
