https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123156
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Last reconfirmed| |2025-12-17
CC| |jakub at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
The permute generated is
{ 1, 0, 0, 0, 0, 1, 1, 0, 1, 1, 1, 1, 0, 1, 1, 0, 0, 0, 1, 0, 1, 1, 1, 1, 0, 0,
0, 0, 1, 0, 0, 0, 1, 1, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 1, 1, 0, 1, 0, 1, 1,
0, 1, 1, 1, 1, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 0, 0, 0, 1, 1, 1,
0, 0, 1, 0, 0, 0, 1, 0, 0, 1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, 0, 1, 1,
0, 1, 0, 0, 1, 0, 1, 1, 0, 1, 1, 1, 1, 1, 0, 0, 0, 1, 0, 0, 0, 1, 0, 1, 0, 1,
1, 1, 0, 1, 1, 0, ...
Also we seem to extend the two-lane source vectors to the number of elements
of the permute, which is wrong?
BS_VAR_0 = {.src= VEC_PERM_EXPR < {<<< Unknown tree: compound_literal_expr
vector(2) unsigned char D.3301 = { 2, 0 }; >>>, { 0, 0 }, ... , { 0, 0
}} , {<<< Unknown tree: compound_literal_expr
vector(2) unsigned char D.3302 = { 0, 0 }; >>>, { 0, 0 }, { 0, 0 }, ...,
{ 0, 0 }} , { 1, 0, 0, 0, ...
It works with 128 elements where we get
{ 1, 0, 128, 128, 128, 129, 1, 128, 129, 1, 129, 129 ...
for the permute. The issue seems to be from the "old" restriction of
VEC_PERM_EXPR where the permute vector elements had to be the same type as
the data elements (uchar) as well as that the source vectors be the same
number of elements and the same number of elements as the permute vector.
All of those restrictions no longer exist, so a simpler translation to
VEC_PERM_EXPR is possible.
Seems I added __builtin_shufflevector.
