This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] libgcc/MIPS: Fill in delay slots of (some) MIPS16 call stubs
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 29 Jul 2013 22:20:38 +0100
- Subject: Re: [PATCH] libgcc/MIPS: Fill in delay slots of (some) MIPS16 call stubs
- References: <alpine dot DEB dot 1 dot 10 dot 1307291809530 dot 32382 at tp dot orcam dot me dot uk> <87k3k9b2d9 dot fsf at talisman dot default>
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.