Re: mips-elf-gcc -fno-delayed-branch problem

[Richard Sandiford <rdsandiford at googlemail dot com>]

Toshi Morita <tm314159@yahoo.com> writes:
> There's a problem where compiling code with -fno-delayed-branch still
> fills branch delay slots.
> [...]
> The problem appears to be caused with GNU AS. It now has the
> capability to reorder instructions, and there is no ".set noreorder"
> emitted by the compiler, so the assembler fills the branch delay slot.

FWIW, I think this was a deliberate historical choice.  But...

> So when the -fno-delayed-branch switch is passed to mips-elf-gcc, a
> ".set noreorder" directive should be emitted into the assembly file.

The problem is that ".set noreorder" has other side-effects too,
such as stopping the assembler from inserting nops to avoid data
hazards, or to work around errata.  There are various situations
in which we can't rely on GCC to insert these nops, and in which
GCC must therefore treat the function as ".set reorder".

One of those situations is when the function has inline asm, as in
your example.  GCC doesn't know what the inline asm does, so it also
doesn't know what nops would be needed between the asm and the
GCC-generated code, or within the asm code itself.  Another situation
is when compiling with -mno-explicit-relocs or with various -mfix-*
options.  While those are somewhat niche options, it'd be inconsistent
to "guarantee" that -fno-delayed-branch emits everything as ".set noreorder"
except when those options are used.

At the moment, the way to force no delayed branches is to use:

    -fno-delayed-branch -Wa,-O0

Maybe it would be worth breaking with tradition and making
-fno-delayed-branch imply -Wa,-O0 though.  Back in the day,
the assembler's version of delayed-branch filling was applied
to pretty much every function, so the separation was probably
more obvious.  However, CCC now tries to emit most functions as
".set noreorder"/ ".set nomacro", so -fno-delayed-branch does
actually stop the assembler filling branches in most situations.
I can see that it'd be confusing to suddenly have the assembler
kick in when you add something like an inline asm.

So yeah, I'll try to get around to that this weekend...

Richard