This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/66573] Unexpected change in static, branch-prediction cost from O1 to O2 in if-then-else.


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]