This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: MIPS assembler branch relaxations
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: binutils at sources dot redhat dot com, echristo at redhat dot com
- Date: Sat, 14 Sep 2002 11:11:21 -0400
- Subject: Re: MIPS assembler branch relaxations
- References: <orr8fxdsby.fsf@free.redhat.lsd.ic.unicamp.br>
On Sat, Sep 14, 2002 at 02:59:45AM -0300, Alexandre Oliva wrote:
> This patch arranges for the MIPS assembler to turn out-of-range
> branches into jumps. No regressions are introduced in the binutils
> testsuites for a mips-linux build. Details on how it is done are in
> comments in the beginning of the patch. Ok to install?
A couple of thoughts:
+ beql reg1, reg2, 1f
+ nop
+ beqzl $0, 2f
+ nop
+ 1: j[al] label
+ delay slot (executed only if branch taken)
+ 2:
Why beqzl? Admittedly, I don't know much about MIPS hardware, but I'd
think that just "b" would probably be faster, since that's the normal
unconditional branch.
+ Even though keeping the delay slot instruction in the delay slot of
+ the branch would be more efficient, it would be very tricky to do
+ correctly, because we'd have to introduce a variable frag *after*
+ the delay slot instruction, and expand that instead. Let's do it
+ the easy way for now, even if the branch-not-taken case now costs
+ one additional instruction. Out-of-range branches are not supposed
+ to be common, anyway.
If this goes in as-is, I doubt that it'll ever be done the right way.
My cynicism speaking.
The above aren't really objections, mind - I agree that performance of
this isn't important. Just observations.
More importantly, because the performance of this is not important or
particularly good, it's important to avoid it. When will it trigger?
Does it require -relax? [Not sure.] Does it happen inside .set
nomacro? [I think so - should it? I'd say not!] I think there should
be a command-line option to disable this, and/or warn about it. Most
out-of-range branches represent bugs in GCC's calculations of
instruction lengths. I know there are some in 3.2, because I've run
into them. I don't know if they're fixed in HEAD, and if this goes in
I may never find out.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer