This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [committed] PR 51931: force non-MIPS16ness for long-branch tests (NOW RFA: MIPS16 Long Branch Patch)
- From: "Moore, Catherine" <Catherine_Moore at mentor dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 18 Jul 2012 16:55:38 +0000
- Subject: RE: [committed] PR 51931: force non-MIPS16ness for long-branch tests (NOW RFA: MIPS16 Long Branch Patch)
- References: <FD3DCEAC5B03E9408544A1E416F1124211F497BE@NA-MBX-04.mgc.mentorg.com> <874nv3spu9.fsf@firetop.home>
Hi Richard,
Now that we are in the window for 4.8, I'd like to discuss the possibility of applying this patch. Have you had a chance to think about it?
Thanks,
Catherine
> -----Original Message-----
> From: Richard Sandiford [mailto:rdsandiford@googlemail.com]
> Sent: Monday, February 06, 2012 2:51 PM
> To: Moore, Catherine
> Cc: Tang, Chung-Lin; gcc-patches@gcc.gnu.org
> Subject: Re: [committed] PR 51931: force non-MIPS16ness for long-branch tests
> (NOW RFA: MIPS16 Long Branch Patch)
>
> Thanks for the patch.
>
> "Moore, Catherine" <Catherine_Moore@mentor.com> writes:
> >> -----Original Message-----
> >> From: Chung-Lin Tang [mailto:cltang@codesourcery.com]
> >> Sent: Monday, January 30, 2012 4:36 AM
> >> To: gcc-patches@gcc.gnu.org; rdsandiford@googlemail.com
> >> Cc: Moore, Catherine
> >> Subject: Re: [committed] PR 51931: force non-MIPS16ness for
> >> long-branch tests
> >>
> >> On 2012/1/22 06:33 PM, Richard Sandiford wrote:
> >> > The MIPS16 port has never handled long branches properly; see PR
> >> > 51931 for the details. It isn't easy to xfail MIPS16-specific
> >> > problems at the dejagnu level because of -mflip-mips16, so the
> >> > patch below forces a nomips16 attribute instead.
> >> >
> >> > Tested on mips64-linux-gnu and applied.
> >> >
> >> > Richard
> >>
> >> CCing Catherine, I think we have a fix for this?
> >>
> >
> > I do have a patch. It's a heuristic and will not work in all
> > instances, but it does allow many additional programs to successfully
> > compile. For example, this scheme allowed me to build glibc in
> > MIPS16-mode for a MIPS-Linux toolchain.
> >
> > The patch causes reorg to examine mips16 branches. For branches that
> > are out-of-range, reorg will look for branches to the same target. If
> > that branch is in range, the destination of the original branch
> > becomes the new branch. If branches to the same target do not exist,
> > then reorg will search for barriers that are in range and insert
> > label+ branch at the barrier.
> >
> > Of the test cases mentioned in the bug report,
> > gcc.c-torture/compile/20001226-1.c still fails due to a lack of
> > barriers in the instruction stream. g++.dg/opt/longbranch1.C will
> > pass.
> >
> > I've set off a test run with my patch applied against mainline. In
> > the meantime, here's the patch. Richard, what do you think?
>
> Yeah, it's difficult. On the one hand, this is probably more efficient (both in
> terms of code size and speed) than a MIPS16 equivalent of the
> non-MIPS16 fallback, which uses a label load followed by an indirect jump.
> On the other hand, it can suffer from degenerate cases where we need so many
> new branches that even the trampolines become out of range.
> (Maybe that's what's happening in the 20001226-1.c case.)
>
> Since this isn't a regression, the patch would need to wait for 4.8 anyway.
> I'll have a think about it before then (or at least try to remember to...)
>
> Thanks,
> Richard