This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: MIPS assembler branch relaxations
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