[Top] [All Lists]

Re: MIPS gas relaxation still doesn't work

To: Alexandre Oliva <>
Subject: Re: MIPS gas relaxation still doesn't work
From: "Maciej W. Rozycki" <>
Date: Tue, 15 Oct 2002 21:37:53 +0200 (MET DST)
Cc: "H. J. Lu" <>, "David S. Miller" <>,,,,
In-reply-to: <>
Organization: Technical University of Gdansk
Original-recipient: rfc822;
Reply-to: "Maciej W. Rozycki" <>
On 15 Oct 2002, Alexandre Oliva wrote:

> The compiler is the right place in which to fix out-of-range jumps,
> because the compiler has better information on how to reduce the
> performance impact of such transformation.  It can be fixed in the
> assembler, but it can't be done as efficiently.

 Except that the compiler does not always have the knowledge, particularly
when inline assembly bits (insolvable) or macros such as "la" (unless gcc
gets a full-blown ABI-dependent machinery implemented) are involved.

 I think at least for the former case gas should be let relax jumps and
branches freely, so the ".set nomacro" statement should be moved to affect
instructions in delay slots only, as you suggested.

 For the latter, gas could be able to move parts of macro expansions into
delay slots and it sometimes succeeds, though it isn't particularly good
at it.  Try to assemble e.g.: "bar: lw $2,foo; b bar" for o32/PIC and for
n32/PIC.  It can't be optimized by gcc, if to be emitted, any further
currently and gas (2.13) fails that miserably for the former: 

lw.o:     file format elf32-tradlittlemips

Disassembly of section .text:

00000000 <bar>:
   0:   8f820000        lw      v0,0(gp)
                        0: R_MIPS_GOT16 foo
   4:   00000000        nop
   8:   8c420000        lw      v0,0(v0)
   c:   1000fffc        b       0 <bar>
  10:   00000000        nop

but it succeeds for the latter!:

lw64.o:     file format elf64-tradlittlemips

Disassembly of section .text:

0000000000000000 <bar>:
   0:   df820000        ld      v0,0(gp)
                        0: R_MIPS_GOT_PAGE      foo
   4:   64420000        daddiu  v0,v0,0
                        4: R_MIPS_GOT_OFST      foo
   8:   1000fffd        b       0 <bar>
   c:   8c420000        lw      v0,0(v0)

So there is still a small gain from letting gas try to fill slots usefully
when gcc can't.  Therefore, I agree with H. J. here -- if gcc is about to
put a "nop" into a branch delay, it'd better give it up together with the
".set noreorder" directive, letting gas try again if it can come with
something better.  This isn't ever going to hurt, whether gcc gets smarter
or not, unless gas stops filling delay slots one day, which is unlikely, I


+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+        e-mail:, PGP key available        +

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