<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On May 4, 2013, at 6:27 PM, Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:</div><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br>Maybe that's not so bad ;) The PPC has a whole perfect-shuffle generation framework to handle these kinds of things for Altivec. Have you ever looked at PPCPerfectShuffle.h and utils/PerfectShuffle/PerfectShuffle.cpp?<span class="Apple-converted-space"> </span></div></blockquote><br></div><div>We use "perfect shuffle" code for ARM Neon, too, except only for vectors with 4 elements. The tables get way too big with 8- and 16-element vectors.</div><div><br></div><div>If InstCombine creates a shuffle for a 16-element Neon vector that doesn't directly match an instruction, you can end up with absolutely terrible code. Until someone comes up with a general solution to that, it is really important that none of the target-independent code create new shuffles that might cause trouble for code-gen.</div></body></html>