linux-mips
[Top] [All Lists]

Re: MIPS gas relaxation still doesn't work

To: "H. J. Lu" <hjl@lucon.org>
Subject: Re: MIPS gas relaxation still doesn't work
From: Richard Sandiford <rsandifo@redhat.com>
Date: 14 Oct 2002 17:35:00 +0100
Cc: aoliva@redhat.com, linux-mips@linux-mips.org, gcc@gcc.gnu.org, binutils@sources.redhat.com
In-reply-to: <20021014091649.A29353@lucon.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20021012113423.A27894@lucon.org> <20021013145423.A10174@lucon.org> <20021014082810.A28682@lucon.org> <wvnit05ovct.fsf@talisman.cambridge.redhat.com> <20021014091649.A29353@lucon.org>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1
"H. J. Lu" <hjl@lucon.org> writes:
> > gcc is usually much better at filling delay slots than gas is.  gas just
> > looks at the previous instruction to see if it's suitable.  gcc can pull
> > pull instructions from the branch target instead.
> 
> I don't think so. Please check out g++.dg/opt/longbranch1.C. gcc 3.2
> generates:
> 
> $L7488:
>         lw      $2,52($fp)
>         .set    noreorder
>         .set    nomacro
> 
>         bne     $2,$0,$L7493
>         nop
>         j       $L2
>         nop
> 
>         .set    macro
>         .set    reorder
> $L7493:
> 
> It is no better than gas and disables the branch relaxation. I don't
> why gcc shouldn't let gas handle it in this case. That is gcc should
> never fill the delay slot with nop.

Huh?  Obviously there are going to be cases when neither gcc nor
gas can fill a slot.  Just because you've found one doesn't mean
that gcc never fills a delay that gas wouldn't.  Compare gcc's
dbr_schedule with gas's append_insn.

The fact gcc fills this slot with a nop is just incidental.
gcc is not written on the assumption that the assembler will
relax branches.  It's easy to see it filling that slot with
a non-nop in other cases.  And, what's more, filling it with
a non-nop that gas wouldn't consider.

When you said:

> Can gcc be be modified not to generate noreorder/nomacro for branchs if
> gas is used?

you seemed to be arguing that gcc should start relying on
branch relaxation, but that really seems the wrong way to go.

Richard

<Prev in Thread] Current Thread [Next in Thread>