https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89570
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to rsand...@gcc.gnu.org from comment #6)
> I think there are two things here:
>
> (1) checking earlier for whether an ifn is supported.
>
> I think we should get genmatch to do that itself rather than
> manually do it for each expansion.
>
> (2) not splitting out the condition in a (vec_)cond_expr if it
> isn't supported as a stand-alone operation
>
> It looks like (2) is the real fix and (1) is a compile-time
> improvement that happens to make (2) latent in this case.
>
> How is it possible for a condition to be supported only in
> a VEC_COND_EXPR? Isn't a stand-alone condition equivalent
> to a VEC_COND_EXPR between {-1, ...} and {0, ...}?
Oops, I've committed already before reading your comments.
Yes, the committed patch does (1). Not really sure it needs to be done in
other patterns that don't introduce IFN_COND_*, those other take IFN_COND_* and
transform that to some other IFN_COND_*.
For VEC_COND_EXPR, yes, it is pretty usual on many of the targets that you can
only do:
_1 = VEC_COND_EXPR <_2 == _3, {-1, -1, ...}, {0, 0, ...}>;
(that is vcond/vcondu/vcondeq optab), and not:
_4 = _2 == _3;
(that is vec_cmp/vec_cmpu/vec_cmpeq optab).
Quick grep for '"vcond' config/*/*.md shows that the former is likely in
aarch64, arm, gcn, i386, ia64, mips, rs6000, s390, sparc, spu
and the latter only in
aarch64, gcn, i386, s390
(haven't checked exact modes).
