From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20816 invoked by alias); 14 Oct 2013 17:53:24 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 20752 invoked by uid 89); 14 Oct 2013 17:53:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: multi.imgtec.com Received: from multi.imgtec.com (HELO multi.imgtec.com) (194.200.65.239) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 14 Oct 2013 17:53:22 +0000 From: Chao-Ying Fu To: 'Richard Sandiford' CC: "'Maciej W. Rozycki'" , "binutils@sourceware.org" Subject: RE: [PATCH] MIPS SIMD Architecture (MSA) patch Date: Mon, 14 Oct 2013 17:53:00 -0000 Message-ID: <81D57523CB07B24881D63DE650C6ED82019053B9@BADAG02.ba.imgtec.org> References: <81D57523CB07B24881D63DE650C6ED82019034B4@BADAG02.ba.imgtec.org> <87siwbr2os.fsf@talisman.default> <81D57523CB07B24881D63DE650C6ED82019039DC@BADAG02.ba.imgtec.org> <874n8rq66j.fsf@talisman.default> <81D57523CB07B24881D63DE650C6ED8201903F16@BADAG02.ba.imgtec.org> <87y561ov0k.fsf@talisman.default> <81D57523CB07B24881D63DE650C6ED8201904312@BADAG02.ba.imgtec.org> <81D57523CB07B24881D63DE650C6ED82019043B7@BADAG02.ba.imgtec.org> <87ppraj37w.fsf@talisman.default> In-Reply-To: <87ppraj37w.fsf@talisman.default> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SEF-Processed: 7_3_0_01192__2013_10_14_18_53_18 X-SW-Source: 2013-10/txt/msg00220.txt.bz2 Richard Sandiford wrote: > Chao-Ying Fu writes: > >> I wonder whether -mmsa is the best name for the 128-bit=20 > option if we > >> know that a 256-bit form might come along. > > > > I am ok with any names. Or, we can add another switch to=20 > specify the > > width of MSA, > > if 256-bit MSA comes along. >=20 > OK. I assume that if a new revision of the ASE comes along=20 > with 256-bit > support, it'll still try to be compatible with the original revision? Yes, I think 256-bit MSA will try to be compatible to 128-bit MSA. The same MSA instruction will operate on 256-bit MSA registers. Hopefully, old code for 128-bit MSA will still run with no or a little bit = helps. > If so, we could end up needing to specify the width and the revision > separately. Yes. >=20 > So maybe it would be better for GCC to have a -mmsa128 option=20 > to specify > the register width. This would be like -mgp32/-mgp64 and=20 > -mfp32/-mfp64. > Then plain -mmsa can be used to specify the revision, a bit like -mdsp > and -mdspr2. (Similarly for ".set dsp(r2)" and ".set msa".) Yes. >=20 > The assembler would only need to know about -mmsa, so there'd=20 > be no changes > to the option handling in the rest of the patch. It's just a=20 > question of > what the GCC option will be called, and what should be used=20 > in these error > messages. Yes. >=20 > > > > Index: include/elf/mips.h > > > >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > RCS file: /cvs/src/src/include/elf/mips.h,v > > > > retrieving revision 1.55 > > > > diff -u -p -r1.55 mips.h > > > > --- include/elf/mips.h 17 Sep 2013 21:05:49 -0000 1.55 > > > > +++ include/elf/mips.h 9 Oct 2013 23:42:58 -0000 > > > > @@ -1135,6 +1135,9 @@ enum > > > >=20=20 > > > > /* Floating-point ABI used by this object file. */ > > > > Tag_GNU_MIPS_ABI_FP =3D 4, > > > > + > > > > + /* MSA ABI used by this object file. */ > > > > + Tag_GNU_MIPS_ABI_MSA =3D 8, > > > > }; > > >=20 > > > These tags are enums rather than bitfields. Are 5-7=20 > already taken? > > > If not, and if this isn't "in the wild" yet, it'd be good to use 5 > > > instead if possible. > > > > The selection of 8 is due to the attr types designed by=20 > bfd/elf-attrs.c. > > Ex: > > /* Determine whether a GNU object attribute tag takes an integer, a > > string or both. */ > > static int > > gnu_obj_attrs_arg_type (int tag) > > { > > /* Except for Tag_compatibility, for GNU attributes we follow the > > same rule ARM ones > 32 follow: odd-numbered tags take strings > > and even-numbered tags take integers. In addition, tag & 2 is > > nonzero for architecture-independent tags and zero for > > architecture-dependent ones. */ > > if (tag =3D=3D Tag_compatibility) > > return 3; > > else > > return (tag & 1) !=3D 0 ? 2 : 1; > > } > > > > Similarly, "include/elf/ppc.h" uses 4, and 8, and 12 for=20 > object attribute tags. >=20 > Doh, hadn't realised that, sorry. >=20 > > > > @@ -513,7 +522,7 @@ const struct mips_arch_choice mips_arch_ > > > > { "mips64r2", 1, bfd_mach_mipsisa64r2, CPU_MIPS64R2, > > > > ISA_MIPS64R2, > > > > (ASE_MIPS3D | ASE_DSP | ASE_DSPR2 | ASE_DSP64 |=20 > ASE_EVA | ASE_MT > > > > - | ASE_MDMX | ASE_MCU | ASE_VIRT | ASE_VIRT64), > > > > + | ASE_MDMX | ASE_MCU | ASE_VIRT | ASE_VIRT64 |=20 > ASE_MSA | ASE_MSA64), > > > > mips_cp0_names_mips3264r2, > > > > mips_cp0sel_names_mips3264r2, ARRAY_SIZE=20 > (mips_cp0sel_names_mips3264r2), > > > > mips_hwr_names_mips3264r2 }, > > > > @@ -738,6 +747,18 @@ parse_mips_dis_option (const char *optio > > > > return; > > > > } > > > >=20=20 > > > > + if (CONST_STRNEQ (option, "msa")) > > > > + { > > > > + mips_ase |=3D ASE_MSA; > > > > + if ((mips_isa & INSN_ISA_MASK) =3D=3D ISA_MIPS64R2) > > > > + { > > > > + mips_ase |=3D ASE_MSA64; > > > > + /* Disable ASE_MDMX, because of opcode conflicts. */ > > > > + mips_ase &=3D ~ASE_MDMX; > > > > + } > > > > + return; > > > > + } > > >=20 > > > Hmm, but you keep MDMX in the default list for mips64r2.=20=20 > > > Maybe we really > > > do need to add mips64r5 :-) > > > > Sure. New work to do. :-) >=20 > Still, adding an incompatible ASE to mips64r2 just seems wrong. > We should either remove ASE_MDMX or leave ASE_MSA* out (of both > the mips32r2 and mips64r2 entries). Since the only in-tree processor > with MDMX support is the MIPS 64r1 SB1, I'm happy with dropping MDMX > if that's easier. There might be some testsuite fallout from doing > that though. I dropped ASE_MDMX from mips64r2 and the testing result is ok. Only the MIPS 64r1 SB1 tests MDMX. If we do add mips32r5 and mips64r5, we will drop ASE_MSA* from mips32r2 and= mips64r2 then. Ex: (mips-dis.c) @@ -513,7 +522,7 @@ const struct mips_arch_choice mips_arch_ { "mips64r2", 1, bfd_mach_mipsisa64r2, CPU_MIPS64R2, ISA_MIPS64R2, (ASE_MIPS3D | ASE_DSP | ASE_DSPR2 | ASE_DSP64 | ASE_EVA | ASE_MT - | ASE_MDMX | ASE_MCU | ASE_VIRT | ASE_VIRT64), + | ASE_MCU | ASE_VIRT | ASE_VIRT64 | ASE_MSA | ASE_MSA64), mips_cp0_names_mips3264r2, mips_cp0sel_names_mips3264r2, ARRAY_SIZE (mips_cp0sel_names_mips3264r2= ), mips_hwr_names_mips3264r2 }, @@ -738,6 +747,14 @@ parse_mips_dis_option (const char *optio return; } + if (CONST_STRNEQ (option, "msa")) + { + mips_ase |=3D ASE_MSA; + if ((mips_isa & INSN_ISA_MASK) =3D=3D ISA_MIPS64R2) + mips_ase |=3D ASE_MSA64; + return; + } + if (CONST_STRNEQ (option, "virt")) { mips_ase |=3D ASE_VIRT; >=20 > OK with those changes, thanks, >=20 > Richard >=20 I will start to check in. Thanks a lot! Regards, Chao-ying