[Bug target/56309] conditional moves instead of compare and branch result in almost 2x slower code

["jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56309

--- Comment #32 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #31)
> But RTL if-conversion still will generate cmov, right?

Sure.

The current if-conversion is performed without any cost model or anything
similar, say even for:
void
foo (int *a, int *b, int *c)
{
  int i;
  for (i = 0; i < 1024; i += 32)
    {
      int t1, t2;
#define V(N) \
      t1 = a[i + N]; t2 = b[i + N]; \
      a[i + N] = c[i + N / 8] ? t1 * (N + 1) / 3 + 21: t2 * (N + 3) / 17 + 9;
      V(0) V(1) V(2) V(3) V(4) V(5) V(6) V(7) V(8) V(9)
      V(10) V(11) V(12) V(13) V(14) V(15) V(16) V(17) V(18) V(19)
      V(20) V(21) V(22) V(23) V(24) V(25) V(26) V(27) V(28) V(29)
      V(30) V(31)
    }
}
it will just if-convert everything together, performing all the operations
unconditionally and doing lots of conditional moves.
If my patches are way to go, supposedly the vectorizer cost model should take
into account the non-if-converted loop cost instead of if-converted loop cost
and compare that to the cost of the vectorized if-converted loop, though with
multiple basic blocks in loop's body there won't be one cost, but perhaps one
can compute minimum and maximum and average cost or something similar (also
taking into account branch probabilities).
And, for targets where a tree if-conversion would be useful, after adding some
cost model and limiting how many statements we should be running
unconditionally, parts of the if-conversion framework could be used for a
different pass.