This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Add *vec_concatv4sf_0 and *vec_concatv4si_0 insns (PR target/88278)
- From: Uros Bizjak <ubizjak at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 2 Dec 2018 21:03:54 +0100
- Subject: Re: [PATCH] Add *vec_concatv4sf_0 and *vec_concatv4si_0 insns (PR target/88278)
- References: <20181130211441.GJ12380@tucnak> <CAFULd4bLijBOhiE-K2xTYyOR-V291CNwZA-DYjm01VdLO6NxNA@mail.gmail.com> <20181202194802.GR12380@tucnak>
On Sun, Dec 2, 2018 at 8:48 PM Jakub Jelinek <email@example.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")
> (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.
> 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