[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 #9 from ktkachov at gcc dot gnu.org ---
(In reply to [email protected] from comment #8)
> 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.

Perhaps, I can certainly believe there is a uarch-dependent component. In this
case it seems that for low-iteration loops the CSEL is better but for long
iterations the cbranch is better as the branch predictor trains on the pattern.
so to distinguish between the two we'd need some niter information. Is that
available/deducible at RTL?