This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [committed] PR 51931: force non-MIPS16ness for long-branch tests (NOW RFA: MIPS16 Long Branch Patch)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]