Re：Re：[RFC] RISC-V: Raise noce if-conversion cost limit

Hi Jeff

> Yea, that could well be the one I was looking at fairly recently. At
> the point where you're considering if-conversion, what values are you
> selecting across?

Thanks for the explanation and the commit reference.
I reduced the MCF case to a small testcase. At the point where RTL
if-conversion is considered, it is not selecting across 1 and -1.
Instead, the same condition controls three pairs of pointer values:
extern void consume (void *, void *, void *);

__attribute__ ((noinline, noclone))
void
select_three_pointers (long x, long y,
                       void *a0, void *a1,
                       void *b0, void *b1,
                       void *c0, void *c1)
{
  if (x > y)
    {
      a0 = a1;
      b0 = b1;
      c0 = c1;
    }

  consume (a0, b0, c0);
}

In other words, the three selections are:
a0 = condition ? a1 : a0;
b0 = condition ? b1 : b0;
c0 = condition ? c1 : c0;

The original comparator in MCF returns 1 or -1, but after med3 and the
comparator are inlined into spec_qsort, that intermediate result is
eliminated. The ID comparison directly controls the three pointer
selections.

I compiled the reduced testcase with:
-O2 -march=rv64gc_zicond -mabi=lp64d
With max-rtl-if-conversion-unpredictable-cost set to 47, the conversion
does not happen and GCC emits a conditional branch followed by three
moves.

With the value set to 48, the ce1 dump reports:
if-conversion succeeded through noce_convert_multiple_sets
and GCC emits one comparison, six czero instructions and three adds,
with no remaining conditional branch in the function.

So this appears to be different from the 1/-1 case you described. The
1/-1 and spaceship improvements may still help the original comparator
before inlining, but the specific if-conversion decision here is for a
multiple-set pointer selection.


Best regards,
Wang Jue