From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1776 invoked by alias); 29 Jul 2013 21:20:57 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 1751 invoked by uid 89); 29 Jul 2013 21:20:56 -0000 X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_50,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RDNS_NONE autolearn=no version=3.3.1 Received: from Unknown (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 29 Jul 2013 21:20:55 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1V3us3-0002Z6-JC from Maciej_Rozycki@mentor.com ; Mon, 29 Jul 2013 14:20:47 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 29 Jul 2013 14:20:47 -0700 Received: from [172.30.64.204] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Mon, 29 Jul 2013 22:20:45 +0100 Date: Mon, 29 Jul 2013 21:36:00 -0000 From: "Maciej W. Rozycki" To: Richard Sandiford CC: Subject: Re: [PATCH] libgcc/MIPS: Fill in delay slots of (some) MIPS16 call stubs In-Reply-To: <87k3k9b2d9.fsf@talisman.default> Message-ID: References: <87k3k9b2d9.fsf@talisman.default> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-07/txt/msg01439.txt.bz2 On Mon, 29 Jul 2013, Richard Sandiford wrote: > > I believe the only legacy MIPS processors that implemented the MIPS16 ASE > > in its original variation (i.e. with no compact jumps, no SAVE/RESTORE, > > and no extend instructions) were the LSI's TinyRISC cores. > > Ah, hadn't realised that the original version had no EXTEND instruction. > Which TinyRISC iteration was that? The LR4102 had it AFAIK. > > FWIW GCC and binutils always assume that EXTEND is available and just > make a distinction between "original MIPS16" (which sounds like it might > not be as original as I'd thought) and "MIPS16e". The VR4121 and VR4131 > were also in the "original MIPS16" category (no compact jumps, SAVE/RESTORE, > etc.). But they also had no FPU. I meant the sign- and zero-extend instructions indeed, not the EXTEND opcode (not really a distinct instruction, more like a prefix), sorry for not being clear enough. Thanks for the reminder of the NEC silicon. > > These stubs are I believe not really covered in our testing, because they > > require a mixed standard-MIPS/MIPS16 environment. > > What's the barrier to testing a mixed environment? The normal *-linux-gnu > configurations have no MIPS16 multilibs, so you should be able to test it > on a plain mips-linux-gnu configuration using --target_flags unix/-mips16. > FWIW I've been using the mips64-linux-gnu equivalent > (--target_flags unix/-mabi=32/-mips16) without problems. > > Or if you don't want to test on GNU/Linux, you should be able to use something > like mips64-elf configured with whichever --with-arch= you like (and an > appropriate simulator). Long time since I tried that though. I prefer > testing on GNU/Linux because it also covers libgcc.so symbol visibility > and has better libgfortran support. We don't have specific coverage, but something in the testsuite might happen to pull one or more of these thunks indeed. > > libgcc/ > > * config/mips/mips16.S (DELAYf): Alias to DELAYt for the MIPS IV > > ISA and up. > > OK, thanks, but please do run it through the testsuite first. I'll see if I can do it -- the MIPS/Linux tree I used for recent MIPS32r2 MADD.fmt testing has no MIPS16 multilibs configured, so it might happen to just work with -mips16 passed as an extra option (otherwise MIPS16 libs would be automagically picked instead). I'll check if binaries executeed really pulled any of the thunks concerned. Maciej