https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78102
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'm not sure it is a good idea. Then expand_vec_cond_expr_p will return true,
vectorizer will use them heavily etc. and the expander will just find out it
can't expand many of those. Looking at expand_vec_cond_expr, it doesn't seem
it would manage the fallback. So, either we'd need some way to differentiate
between various comparison codes for vcond, the problem is that the optab
already now has 2 modes and thus is expensive, adding another parameter would
bloat too much. Or have on the side target hook that
expand_vec_cond_expr_p/expand_vec_cmp_expr_p could use to find out what
comparison codes are supported?
