https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96528
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|enhancement |normal
CC| |rearnsha at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, I configured exactly as in the description but I do not manage to get nice
code even when veclower sees
_1 = a_5(D) == { 5, 5, 5, 5 };
_2 = VEC_COND_EXPR <_1, { -1, -1, -1, -1 }, { 0, 0, 0, 0 }>;
_3 = b_6(D) == { 7, 7, 7, 7 };
_4 = VEC_COND_EXPR <_3, { -1, -1, -1, -1 }, { 0, 0, 0, 0 }>;
_7 = _2 | _4;
return _7;
I guess I'm missing magic compiler options (as usual with arm...).
Besides 'fixing' the arm backend we can either ISEL the compares as
.VCOND, adjust them in veclower to supported VEC_COND_EXPRs
(need to adjust veclower anyway to not generate the awkward code).
I'll note that the arm backend in its vcond* neon patterns seems to
emit two instructions, a mask generating one and a selecting one
where the mask generating one isn't exposed to the middle-end
(that would be vec_cmp* patterns).
So for the specific case of arm neon I agree the best fix would be
to the target. It might be possible to copy the aarch64 patterns here.
