gimple-isel: Fall back to using vcond_mask [PR98560]
authorRichard Sandiford <richard.sandiford@arm.com>
Thu, 7 Jan 2021 15:00:38 +0000 (15:00 +0000)
committerRichard Sandiford <richard.sandiford@arm.com>
Thu, 7 Jan 2021 15:00:38 +0000 (15:00 +0000)
commit78595e918ee168f595d16268073a3754c64d67fe
tree914c3e89c396d7605ea24d6dd356e0e5bc0d7944
parentd54be5ad210b05274fbe43f9f61f9e903aabefb0
gimple-isel: Fall back to using vcond_mask [PR98560]

PR98560 is about a case in which the vectoriser initially generates:

  mask_1 = a < 0;
  mask_2 = mask_1 & ...;
  res = VEC_COND_EXPR <mask_2, b, c>;

The vectoriser thus expects res to be calculated using vcond_mask.
However, we later manage to fold mask_2 to mask_1, leaving:

  mask_1 = a < 0;
  res = VEC_COND_EXPR <mask_1, b, c>;

gimple-isel then required a combined vcond to exist.

On most targets, it's not too onerous to provide all possible
(compare x select) combinations.  For each data mode, you just
need to provide unsigned comparisons, signed comparisons, and
floating-point comparisons, with the data mode and type of
comparison uniquely determining the mode of the compared values.
But for targets like SVE that support “unpacked” vectors,
it's not that simple: the level of unpacking adds another
degree of freedom.

Rather than insist that the combined versions exist, I think
we should be prepared to fall back to using separate comparisons
and vcond_masks.  I think that makes more sense on targets like
AArch64 and AArch32 in which compares and selects are fundementally
separate operations anyway.

gcc/
PR tree-optimization/98560
* gimple-isel.cc (gimple_expand_vec_cond_expr): If we fail to use
IFN_VCOND{,U,EQ}, fall back on IFN_VCOND_MASK.

gcc/testsuite/
PR tree-optimization/98560
* gcc.dg/vect/pr98560-1.c: New test.
gcc/gimple-isel.cc
gcc/testsuite/gcc.dg/vect/pr98560-1.c [new file with mode: 0644]