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

[Richard Sandiford <rdsandiford at googlemail dot com>]

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