On Fri, Aug 13, 2021 at 11:04 AM Richard Sandiford via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > Jakub Jelinek via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > > On Fri, Aug 13, 2021 at 09:42:00AM +0800, Hongtao Liu wrote: > >> > So, I wonder if your new routine shouldn't be instead done after > >> > in ix86_expand_vec_perm_const_1 after vec_perm_1 among other 2 insn cases > >> > and handle the other vpmovdw etc. cases in combine splitters (see that we > >> > only use low half or quarter of the result and transform whatever > >> > permutation we've used into what we want). > >> > > >> Got it, i'll try that way. > > > > Note, IMHO the ultimate fix would be to add real support for the > > __builtin_shufflevector -1 indices (meaning I don't care what will be in > > that element, perhaps narrowed down to an implementation choice of > > any element of the input vector(s) or 0). > > As VEC_PERM_EXPR is currently used for both perms by variable permutation > > vector and constant, I think we'd need to introduce VEC_PERM_CONST_EXPR, > > which would be exactly like VEC_PERM_EXPR, except that the last operand > > would be required to be a VECTOR_CST and that all ones element would mean > > something different, the I don't care behavior. > > The GIMPLE side would be fairly easy, except that there should be some > > optimizations eventually, like when only certain subset of elements of > > a vector are used later, we can mark the other elements as don't care. > > Another alternative I'd wondered about was keeping a single tree code, > but adding an extra operand with a “care/don't care” mask. I think > that would fit with variable-length vectors better.
That sounds reasonable. Note I avoided "quaternary" ops for BIT_INSERT_EXPR but I don't see a good way to avoid that for such VEC_PERM_EXPR extension. Richard. > Thanks, > Richard
