This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/66573] Unexpected change in static, branch-prediction cost from O1 to O2 in if-then-else.
- From: "jvg1981 at aim dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sat, 21 Nov 2015 14:40:18 +0000
- Subject: [Bug tree-optimization/66573] Unexpected change in static, branch-prediction cost from O1 to O2 in if-then-else.
- Auto-submitted: auto-generated
- References: <bug-66573-4 at http dot gcc dot gnu dot org/bugzilla/>
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).