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:rdsandif...@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_mo...@mentor.com> writes: > >> -----Original Message----- > >> From: Chung-Lin Tang [mailto:clt...@codesourcery.com] > >> Sent: Monday, January 30, 2012 4:36 AM > >> To: gcc-patches@gcc.gnu.org; rdsandif...@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
