Re: [RFA] optimizing predictable branches on x86

[Jan Hubicka <hubicka at ucw dot cz>]

> 
> >>>I hope so too. For the kernel we have some parts where
> >>>__builtin_expect is used quite a lot and noticably helps, and could
> >>>help even more if we cut down the use of cmov too. I guess on
> >>>architectures with even more predictated instructions it could be
> >>>even more useful too.
> >>Looking at kernel's __builtin_expect usage, I think we ought to do a lot
> >>better on taking the hints than we do now.  In particular we should
> >>be able to derrive more from
> >> likely (test1||test2) and likely (test1&&test2)
> >>and similar cases.  I will try to prepare patch for this later too.
> 
> Right now it does
> 
>   1. __b_e (a && b, 1) => __b_e (a, 1) && __b_e (b, 1)
>   2. __b_e (a && b, 0) => a && __b_e (b, 0)
>   3. __b_e (a || b, 1) => a || __b_e (b, 1)
>   4. __b_e (a || b, 0) => __b_e (a, 0) || __b_e (b, 0)
> 
> See http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00410.html

Andrew pointed me to that patch few weeks ago.  While we do it as part
of fold, we still miss some cases that results from inlining and other
transfromations.  We probably should be able to perform it at gimple
during fold_builtins pass where current fold behaviour does not match.
Recently I've made simple patch to dump __builtin_expects that are
complettely ignored and this seemed surprisingly common case even with
folder on place.

Other cases was missed fold oppurtunities like __builtin_expect (a==5,1)
and (a+5,1) that if applied to all uses of a dominated by the expect
call would lead to useful predictions but not with our simplified
handling.

Honza
> 
> Paolo