https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
Joshua Green changed:
What|Removed |Added
CC||jvg1981 at aim dot com
--- Comment #17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #20 from Joshua Green ---
> "But if we don't know which pointer is greater, it gets more complicated:
> ..."
>
> I'm not sure that this is true. For types that are larger than 1 byte, it
> seems that one can do the subtraction after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66573
jvg1981 at aim dot com changed:
What|Removed |Added
CC||jvg1981 at aim dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66573
--- Comment #7 from Joshua Green ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66573
--- Comment #9 from Joshua Green ---
(In reply to Segher Boessenkool from comment #8)
> GCC does some fairly involved prediction (in predict.c). It isn't
> "a priori".
>
> > (It's also not clear HOW this could be "faster
> > on essentially all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66573
--- Comment #11 from Joshua Green ---
(In reply to Segher Boessenkool from comment #10)
> GCC thinks bar2 will be executed more often that bar1; the code
> it generates is perfectly fine for that.
>
> If you think GCC's heuristics for branch pre
