> > >>>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
