https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54939
--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 3 Jan 2019, segher at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54939 > > --- Comment #9 from Segher Boessenkool <segher at gcc dot gnu.org> --- > I think we should declare one of the forms canonical, and make simplify > use that one, if possible. If we really want one form in some cases and > another in other cases something like change_zero_ext will work. Yeah, the main issue is that targets have existing patterns prefering either form. vec_merge avoids the need of wider intermediate modes but with vec_select it's easier to allow constrained operands... So IMHO RTL shouldn't have both but it would be convenient to not need that wider mode... it might ask for a vec_concat_and_select (aka vec_shuffle2). Another issue with vec_merge is the limit of the bitmask operand (CONST_INT) which limits us to 64 vector elements. That said, kill vec_merge and allow (vec_select:V4DF (vec_concat:V8DF (reg:V4DF...) (reg:V4DF...)) (parallel [ (const_int 0) ....]))) to be written as (vec_shuffle:V4DF (reg:V4DF...) (reg:V4DF...) (parallel [ (const_int 0) ....]))) note vec_concat operands are not constrained in any way but vec_shuffle would be? That is, in practice targets can probably get rid of vec_merge by using vec_select/vec_concat "easily" even if that means introducing of "fake" larger vector modes.
