Re: [PATCH] Add *vec_concatv4sf_0 and *vec_concatv4si_0 insns (PR target/88278)

[Jakub Jelinek <jakub@redhat.com>]

On Sun, Dec 02, 2018 at 08:23:21PM +0100, Uros Bizjak wrote:
> OK with a constraint adjustment below.
> 
> > +(define_insn "*vec_concatv4sf_0"
> > +  [(set (match_operand:V4SF 0 "register_operand"       "=v")
> > +       (vec_concat:V4SF
> > +         (match_operand:V2SF 1 "nonimmediate_operand" "xm")
> 
> The constraint here can be "vm". There is no limitation on register
> set for vmovq insn.

That is what vec_concatv2df has also:
(define_insn "vec_concatv2df"
  [(set (match_operand:V2DF 0 "register_operand"     "=x,x,v,x,v,x,x, v,x,x")
        (vec_concat:V2DF
          (match_operand:DF 1 "nonimmediate_operand" " 0,x,v,m,m,0,x,xm,0,0")
          (match_operand:DF 2 "nonimm_or_0_operand"  " x,x,v,1,1,m,m, C,x,m")))]

I believe ix86_hard_regno_mode_ok just doesn't allow V2SFmode in xmm16+ regs:
  if (SSE_REGNO_P (regno))
    {
...
      /* xmm16-xmm31 are only available for AVX-512.  */
      if (EXT_REX_SSE_REGNO_P (regno))
        return false;

and V2SFmode is a VALID_MMX_REG_MODE, which is not mentioned anywhere before
the the above conditional, only after it.
While vmovq doesn't have this limitation, I believe RA will not try to put
anything V2SFmode in those regs if lucky, otherwise it could be upset about
it.  Though, DFmode in the vec_concatv2df is different, because
ix86_hard_regno_mode_ok should allow that in those registers, as DFmode is
VALID_AVX512F_SCALAR_MODE.

	Jakub