From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24106 invoked by alias); 28 Jul 2014 12:05:01 -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 24009 invoked by uid 89); 28 Jul 2014 12:05:00 -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,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mailapp01.imgtec.com Received: from mailapp01.imgtec.com (HELO mailapp01.imgtec.com) (195.59.15.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 28 Jul 2014 12:04:59 +0000 Received: from KLMAIL01.kl.imgtec.org (unknown [192.168.5.35]) by Websense Email Security Gateway with ESMTPS id 1C1147707C1F7; Mon, 28 Jul 2014 13:04:53 +0100 (IST) Received: from LEMAIL01.le.imgtec.org (192.168.152.62) by KLMAIL01.kl.imgtec.org (192.168.5.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 28 Jul 2014 13:04:54 +0100 Received: from LEMAIL01.le.imgtec.org ([fe80::5ae:ee16:f4b9:cda9]) by LEMAIL01.le.imgtec.org ([fe80::5ae:ee16:f4b9:cda9%17]) with mapi id 14.03.0195.001; Mon, 28 Jul 2014 13:04:53 +0100 From: Matthew Fortune To: Richard Sandiford CC: "binutils@sourceware.org" , "Moore, Catherine" , "macro@codesourcery.com" , "Joseph Myers (joseph@codesourcery.com)" Subject: RE: [PATCHv4] Add support for O32 FPXX ABI Date: Mon, 28 Jul 2014 12:05:00 -0000 Message-ID: <6D39441BF12EF246A7ABCE6654B0235320EB4A44@LEMAIL01.le.imgtec.org> References: <6D39441BF12EF246A7ABCE6654B0235320EB4042@LEMAIL01.le.imgtec.org> <87fvhnma8u.fsf@talisman.default> In-Reply-To: <87fvhnma8u.fsf@talisman.default> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2014-07/txt/msg00213.txt.bz2 Richard Sandiford writes: > Matthew Fortune writes: > > @@ -258,6 +258,10 @@ struct mips_set_options > > Changed by .set singlefloat or .set doublefloat, command-line > options > > -msingle-float or -mdouble-float. The default is false. */ > > bfd_boolean single_float; > > + > > + /* 1 if single-precision operations on odd-numbered registers are > > + not allowed (even if supported by ISA_HAS_ODD_SINGLE_FPR). */ > > + int nooddspreg; > > }; >=20 > I think "oddspreg" would be better, partly for consistency with the > ISA_HAS_* macro and partly to avoid the double negative in things like: >=20 > bfd_boolean oddspreg =3D (ISA_HAS_ODD_SINGLE_FPR (mips_opts.isa, > mips_opts.arch) > || FPR_SIZE =3D=3D 64) > && !mips_opts.nooddspreg; OK. There was a reason this worked better as nooddspreg to start with but it appears long since gone. > > - /* Single-precision coprocessor loads and moves are OK too. */ > > + /* Single-precision coprocessor loads and moves are OK for 32-bit > registers, > > + otherwise it depends on oddspreg. */ > > if ((insn->pinfo & FP_S) > > - && (insn->pinfo & (INSN_COPROC_MEMORY_DELAY | INSN_STORE_MEMORY > > - | INSN_LOAD_COPROC_DELAY | INSN_COPROC_MOVE_DELAY))) > > + && (insn->pinfo & INSN_FP_32_MOVE)) > > + return FPR_SIZE =3D=3D 32 || oddspreg; >=20 > Why do you need a new flag for this? There are two reasons for this. The lwxc1 instruction is just an INSN_LOAD_MEMORY. I could however just add that to the list of flags to check (and remove INSN_COPROC_MEMORY_DELAY if the LOAD is added)... but the bigger reason is that the micromips mtc1/mfc1 instructions are not INSN_COPROC_MOVE_DELAY so there is no flag to detect them. This has never been a problem before as there has always been 32 single precision registers for micromips but now that may be restricted to 16 depending on ABI. I could just attach a new flag to the micromips instructions which lack any other flag but it seems clearer to attach it to the others too. The only other option is to add INSN_COPROC_MOVE_DELAY to the mtc1/mfc1 instructions in micromips even though that is something of a lie. What do you think is cleanest? I would also like to get rid of all the ctc1/cfc1/cttc1/cftc1 instructions that allow the use of floating point register names: $f0. The problem with these is that they don't actually write floating point registers but they will interact with the oddspreg logic as their operands have type OP_REG_FP. Anything relying on ctc1 $0, $f[0-31] is probably expecting the wrong thing to happen anyway. If that's OK I'll do a separate patch? Thanks, Matthew