Re: MIPS assembler branch relaxations

[Eric Christopher <echristo@redhat.com>]

> +   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.