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
hope.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +