[Bug middle-end/85740] Non-optimal determining maximum in a loop

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85740

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Thomas Koenig from comment #5)
> (In reply to Andrew Pinski from comment #1)
> > These functions are not functional equivalent.
> > 
> > In the b.c, it records the max location but it is the last element which
> > contains that value.  While in c.c, the first element which contains the
> > value is recorded.
> 
> I do not understand.
> 
> The only difference between the files is
> 
> $ diff -u -b b.c c.c
> --- b.c 2018-05-10 22:22:06.276904322 +0200
> +++ c.c 2018-05-10 22:21:50.028801008 +0200
> @@ -14,7 +14,7 @@
>    nm = -1;
>    for (i=0; i<n; i++)
>      {
> -      if (__builtin_expect (a[i] > m, 0))
> +      if (a[i] > m)
>         {
>           m = a[i];
>           nm = i;
> 
> Does this change the semantics of the comparison? If it does, it
> would be a bug in __builtin_expect.

The documentation is hard to understand but you are correct that it just says
we are expecting the value of the comparison to be false.

Anyways the problem here is a bit more complex than just marking the edge as
expect.

For aarch64 we produce csel (which is basically cmov) for both loops:
.L11:
        ldr     w4, [x5, x2, lsl 2]
        cmp     w3, w4
        csel    w0, w0, w2, ge
        add     x2, x2, 1
        csel    w3, w3, w4, ge
        cmp     w1, w2
        bgt     .L11