https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93637
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:f57aa9503ff170ff6c8549718bd736f6c8168bab
commit r10-6565-gf57aa9503ff170ff6c8549718bd736f6c8168bab
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93637
--- Comment #5 from Jakub Jelinek ---
It is a blend, so yes, it can be represented as VEC_PERM_EXPR, or using
vcond_mask_optab etc.
The trouble is that TARGET_AVX && !TARGET_AVX2 is really weird when 32-byte
integral modes are involved and the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93637
--- Comment #4 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #3)
> _80 = VEC_COND_EXPR <{ -1, -1, 0, -1 }, { 5, 6, 7, 8 }, _28>;
Isn't a constant argument 0 for VEC_COND_EXPR really a VEC_PERM?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93637
--- Comment #3 from Jakub Jelinek ---
The problem is that with -mavx -mno-avx2, we have vcondv4div4df optab, but not
vcondv4div4di. Before fre4 we have:
vect_cst__5 = { 0.0, 0.0, 1.0e+0, 0.0 };
...
_55 = [0] + 32;
MEM [(double *)_55] =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93637
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93637
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
