[Bug tree-optimization/126946] [14/15/16/17 Regression] Phiopt lengthening dependency chain in loop for MIN/MAX operations

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

--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> ---
> Am 19.08.2026 um 16:35 schrieb ktkachov at gcc dot gnu.org <[email protected]>:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126946
> 
> --- Comment #4 from ktkachov at gcc dot gnu.org ---
> (In reply to [email protected] from comment #3)
>>> On Wed, 19 Aug 2026, ktkachov at gcc dot gnu.org wrote:
>>> 
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126946
>>> 
>>> --- Comment #2 from ktkachov at gcc dot gnu.org ---
>>> (In reply to Richard Biener from comment #1)
>>>> So why does RTL if-conversion not produce the fcsel?  (and why do we have
>>>> such strange BB order)
>>>> 
>>>> The COND_EXPR allows the x86 cmov expander to pattern-match its FP MIN/MAX
>>>> operations which match IEEE semantics of m < a ? a : m
>>>> 
>>>> On trunk I do see fcsel being used on aarch64 just fine for your testcase,
>>>> so what "fixed" it there?
>>>> 
>>>> .L3:
>>>>        ldr     s31, [x1, x2, lsl 2]
>>>>        add     x2, x2, 1
>>>>        fabs    s31, s31
>>>>        fcmpe   s31, s0
>>>>        fcsel   s0, s31, s0, gt
>>>>        cmp     x0, x2
>>>>        bne     .L3
>>>>        ret
>>>> 
>>>> We expand from
>>>> 
>>>>  _4 = MEM[(const float *)x_9(D) + _20 * 4];
>>>>  a_10 = ABS_EXPR <_4>;
>>>>  _12 = a_10 > m_16;
>>>>  _11 = _12 ? a_10 : m_16;
>>> 
>>> In this case we do not want fcsel. GCC 13 kept the well-predicted branch
>>> whereas GCC 14 starting using fcsel unconditionally because COND_EXPR expansion
>>> goes through the movcc optabs
>> 
>> How do you know the branch is well-predicted?  In general I'd
>> expect its probability to change during the iteration given
>> m grows assuming even distributed x[i].
> 
> In the full application we measured the misprediction rates with HW counters
> and did an A/B comparison with just that fcsel/branch decision changed to
> measure the speedup.
> In this reduced example I think the argument is that the mispredict happens
> whenever the max is updated. Therefore each time it's updated it becomes less
> likely to update again i.e. mispredict since the max is raised so there's fewer
> values left in the domain that are greater than the new max. So for large
> enough n the mispredict rate should be dropping, whereas the fact that the
> running max is a loop recurrence means that a wide core suffers from the
> increased dependency chain of the fcsel.

That would then suggest any such MAX (like with fast-math) are problematic (but
required for vectorization).  So why does the movcc expander not turn this back
to a branch?  Likewise when expanding from max()?

> --
> You are receiving this mail because:
> You are on the CC list for the bug.