https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117173
--- Comment #8 from GCC Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:006b4e45f3ab169a47146b31d9721c79098236ac
commit r15-7235-g006b4e45f3ab169a47146b31d9721c79098236ac
Author: Robin Dapp
Date: Thu Oct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117173
--- Comment #7 from Richard Biener ---
To say that - we expect the backends to output the optimal sequence for each
permute. The limit is that for a series of permutes this doesn't consider
the case where there might be more "complex" permutes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117173
--- Comment #6 from Jakub Jelinek ---
Please have a look at the i386 backend, where for constant permutes it tries a
sequence of 1, 2, 3, 4 or even 5 instructions to do the various permutations.
It isn't perfect and surely misses some cases tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117173
--- Comment #5 from Richard Biener ---
That said - maybe you shouldn't advertise two-input permutes that are not
blends as supported? Of course interleaving { 0, 8, 1, 9, 2, 10 ... }
is such a kind. It should be doable with a vslideup instead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117173
--- Comment #4 from Richard Biener ---
I can see the difficulty here. Note a strathegy for decomposition would be
to produce a monotonic permute of any two input vector permute by noting
elements needed in the final result. If it's possible to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117173
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |target
Keywords|
