https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66573
--- Comment #7 from Joshua Green <jvg1981 at aim dot com> --- (In reply to Segher Boessenkool from comment #6) > bb-reorder changes the conditional branch so that the fallthrough path > is the most likely. It now also does this for -O1. This is faster on > essentially all processors, including the ones the OP mentions. > > Without profiling information showing otherwise, GCC assumes the call > to bar2 is more frequent than the one to bar1 (61% vs. 39%). This is > a heuristic, it might need retuning, but that needs a lot more data > than this one testcase. > > Closing as invalid. While I agree that this isn't really a bug, I find the above reasoning hard to follow. The compiler could treat the original foo as if (i) { bar1(); } else { bar2(); } or if (!i) { bar2(); } else { bar1(); } and I see no reason why expecting the "else" block should a priori be preferable in either case. (It's also not clear HOW this could be "faster on essentially all processors" in either case, though I'm open to being corrected and/or enlightened on this subject.) Of course, the compiler is free to make whatever guess it wants, but it would be nice if the programmer had some portable way of expressing his/her own expectations, and it seems that other compilers provide that by "agreeing" to expect the "if" block (as, indeed, various online articles recommend).