https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92803
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #4) > Though, there is another issue, for the nelts 2 vectors > simplify_vector_constructor created code is actually larger than old code. > And, it might be beneficial if we one day implement clang-like > __builtin_shufflevector or at least add to VEC_PERM_EXPR or something > similar the possibility to say certain element is a don't care (for > __builtin_shufflevector I think that is -1 or negative?), as e.g. on > AVX/AVX2 when extracting 128-bit vector out of 256-bit permutation all the > upper elements are don't care and we might get better code if the backend > picks the best element indexes for those to get smallest/fastest permutation. Using -1 as the don't care element also occured to me. Should be easy to change for the vec_perm_const hook/expander I guess. Not sure about VEC_PERM_EXPR given it also allows non-constant permutation vectors. I thought about relaxing VEC_PERM_EXPR to support extract (destination with less lanes than source(s)) and concat (destination with more lanes than source(s)). Plus eventually allowing sources and destinations to be scalars (interpret as punned to 1-element vector), which would be syntactic sugar given explicit punning would be possible. It would be nice to not expose that to the targets given that explodes the complexity of vec_perm[_const] though. Anyway, this isn't something for GCC 10, but yes, don't know would come in handy.
