"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
