https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88278
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note, we also have vec_concatv2di pattern that handles:
(set (match_operand:V2DI 0 ("register_operand") ("=Yr,*x,x ,v ,v,v ,x
,x,v ,x,x,v"))
(vec_concat:V2DI (match_operand:DI 1 ("nonimmediate_operand") ("
0, 0,x ,Yv,r,vm,?!*y,0,Yv,0,0,v"))
(match_operand:DI 2 ("nonimm_or_0_operand") (" rm,rm,rm,rm,C ,C
,C ,x,Yv,x,m,m"))))
and then *vec_concatv4si which handles far less than that, just the last 5
alternatives. Conceptually, both operations do the same thing, on the other
side not sure if it is a good idea to say to RA that it could put V2SImode
pseudos into GPRs. So, that leaves us at the first pinsrq alternatives with
just "m" for them, not really sure they are worth it. Then there is one v <-
r, C alternative, again, I think we shouldn't put V2SImode into GPRs, v <- vm,
C alternative that we definitely want, but it could be a separate
*vec_concatv4si_0
pattern two, as nonimmediate_operand and const0_operand don't overlap and last
x <- ?!*y, C, that's MMXish, maybe, maybe not.
