https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117173
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> --- So on the GIMPLE side this is mostly canonicalization - the "theory" is that the backend should be able to implement VEC_PERM_EXPR <a, b, NEW_VCST> using the same two cheap permutes facing this premute request. I don't see where the first permute has a single source vector though? So to answer your question: - yes! costing permutes more accurately would be good - no! match.pd should not look at costs can you clarify with the very concrete permutes that happen in x264 how the original two are cheap and the new single is not?
