On Sun, Dec 2, 2018 at 8:48 PM Jakub Jelinek <ja...@redhat.com> wrote: > > 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;
IIRC, RA just won't allocate a register with a regno that won't satisfy hard_regno_mode_ok. The quoted vec_concatv2df looks like an unintended oversight (DFmode is supported in AVX512 regs through VALID_AVX512F_SCALAR_MODE). But we can stay on the safe side and leave MMX modes with "x" constraint. So, patch is OK as is. Thanks, Uros. > 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