[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 #8 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 19 Aug 2026, ktkachov at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126946
> 
> --- Comment #6 from ktkachov at gcc dot gnu.org ---
> (In reply to [email protected] from comment #5)
> > > 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()?
> 
> Yes, with my measurements (on Grace) the scalar fmax is slower than a branch
> when it's a loop-carried recurrence (about 2x slower vs the 4x slower version
> of the fcsel)
> 
> I think there is logic during expansion for choosing between branch and cmov in
> expand_expr_real_2 e.g. there's expand_cond_expr_using_cmove, but it doesn't
> take loop recurrence into account

IMO all this breaking of recurrences for (small) loops should be done
on RTL rather than on GIMPLE given it's really micro-architectural
details that influence things.  For example on x86 some uarchs have
special loop uop machinery that are quite constrained with respect
to code layout.