https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126946
--- Comment #3 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 #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].
