This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: MIPS assembler branch relaxations
> + 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.
>
It's a good comment, however, a couple of other comments:
1) If this bites assembler programmers then they screwed themselves.
2) gcc is going towards .set nomacro, so, hopefully this is just
temporary.
>
> 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.
>
1) None of the other relaxations require a command line.
2) always.
3) no
4) shouldn't - good catch.
5) not always, macros are partially to blame.
6) you and i had a conversation about this very thing yesterday :)
Anyhow, if 4 is I'm pretty happy with it going in.
-eric
--
Yuppies wear socks.