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 +
