Re: MIPS assembler branch relaxations

[Daniel Jacobowitz <drow at mvista dot com>]

On Sat, Sep 14, 2002 at 11:20:35AM -0700, Eric Christopher wrote:
> 
> > +   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.

Fine.

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

Er... um... could I get that said again with more words?  I have no
idea what you just said.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer