"H. J. Lu" <email@example.com> 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
> lw $2,52($fp)
> .set noreorder
> .set nomacro
> bne $2,$0,$L7493
> j $L2
> .set macro
> .set reorder
> 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.