-fno-delayed-branch and the bne-instruction on MIPS

-fno-delayed-branch and the bne-instruction on MIPS

[Simon Kagstrom]

Hello!

I'm working on a binary translator that translates MIPS binaries into
Java bytecode (http://spel.bth.se/index.php/Cibyl) with the goal of
"recompiling" C programs to run on J2ME.  To simplify things, I use
compile programs for a subset of the MIPS1 instruction set, and
ideally I would like to get rid of delayed instructions.

So, I used the -fno-delayed-branch instruction when compiling, which
is documented as

     If supported for the target machine, attempt to reorder
     instructions to exploit instruction slots available after delayed
     branch instructions.

I use GCC 3.4.4 from the emdebian project,

     mips-linux-gcc (GCC) 3.4.4 20050314 (prerelease) (Debian 3.4.3-13)

-fno-delayed-branch seems to mostly work, i.e., I get code as

     10001d0:       27a40010        addiu   a0,sp,16
     10001d4:       0c400008        jal     1000020 <game_loop>
     10001d8:       00000000        nop

which is what I want. However, on conditional branches, it doesn't
work as expected:

     1000160:       8c670000        lw      a3,0(v1)
     1000164:       24020013        li      v0,19
     1000168:       0000000c        syscall
     100016c:       25080001        addiu   t0,t0,1
     1000170:       29020018        slti    v0,t0,24
     1000174:       1440fff9        bnez    v0,100015c <game_init+0x7c>
     1000178:       24630060        addiu   v1,v1,96

Here, I would have expected that the addiu would go before bnez, and
that a nop is inserted after the branch.


So the question is if this is the intended behavior, or if it simply
is a bug with the -fno-delayed-branch implementation? 

// Simon

Re: -fno-delayed-branch and the bne-instruction on MIPS

[Ian Lance Taylor]

Simon Kagstrom <simon.kagstrom@bth.se> writes:

> So, I used the -fno-delayed-branch instruction when compiling, which
> is documented as
> 
>      If supported for the target machine, attempt to reorder
>      instructions to exploit instruction slots available after delayed
>      branch instructions.
> 
> I use GCC 3.4.4 from the emdebian project,
> 
>      mips-linux-gcc (GCC) 3.4.4 20050314 (prerelease) (Debian 3.4.3-13)
> 
> -fno-delayed-branch seems to mostly work, i.e., I get code as
> 
>      10001d0:       27a40010        addiu   a0,sp,16
>      10001d4:       0c400008        jal     1000020 <game_loop>
>      10001d8:       00000000        nop
> 
> which is what I want. However, on conditional branches, it doesn't
> work as expected:
> 
>      1000160:       8c670000        lw      a3,0(v1)
>      1000164:       24020013        li      v0,19
>      1000168:       0000000c        syscall
>      100016c:       25080001        addiu   t0,t0,1
>      1000170:       29020018        slti    v0,t0,24
>      1000174:       1440fff9        bnez    v0,100015c <game_init+0x7c>
>      1000178:       24630060        addiu   v1,v1,96
> 
> Here, I would have expected that the addiu would go before bnez, and
> that a nop is inserted after the branch.
> 
> 
> So the question is if this is the intended behavior, or if it simply
> is a bug with the -fno-delayed-branch implementation? 

This looks like a bug to me.  You may want to open a bug report; see
    http://gcc.gnu.org/bugs.html

I suspect the bug is that -fdelayed-branch is failing to pass -O0 to
the assembler.  Try compiling with -Wa,-O0.

Ian

Re: -fno-delayed-branch and the bne-instruction on MIPS

[Simon Kagstrom]

At 07 Jul 2006 10:32:28 -0700,
Ian Lance Taylor wrote:
> 
> Simon Kagstrom <simon.kagstrom@bth.se> writes:
> 
> > So, I used the -fno-delayed-branch instruction when compiling, which
> > is documented as
> > [...]
> 
> This looks like a bug to me.  You may want to open a bug report; see
>     http://gcc.gnu.org/bugs.html
> 
> I suspect the bug is that -fdelayed-branch is failing to pass -O0 to
> the assembler.  Try compiling with -Wa,-O0.

Unfortunately there was no difference with -Wa,-O0. It does however
look like the use of Linux-style syscalls break the
-fno-delayed-branch behavior. I have code like

   #define _syscall1(type,name,atype,a) \
   type name(atype a) \
   { \
	   register unsigned long __a0 asm("$4") = (unsigned long) a; \
	   register unsigned long __v0 asm("$2"); \
	   \
	   __asm__ volatile ( \
	   ".set\tnoreorder\n\t" \
	   "li\t$2, %2\t\t\t# " #name "\n\t" \
	   "syscall\n\t" \
	   ".set\treorder" \
	   : "=&r" (__v0) \
	   : "r" (__a0), "i" (__NR_##name) \
	   ); \
	   \
	   return (type) __v0; \
   }
   #define __NR_exit 0
   static inline _syscall1(void,exit , int, code );

and with the call of exit(...), the delay slots are filled with
instructions. If I just define a plain function and call that,
-fno-delayed-branch seems to behave correctly.


Anyway, I've submitted a bug report at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28325


Thanks for the input!

// Simon

Re: -fno-delayed-branch and the bne-instruction on MIPS

[Ian Lance Taylor]

Simon Kagstrom <simon.kagstrom@bth.se> writes:

> Unfortunately there was no difference with -Wa,-O0. It does however
> look like the use of Linux-style syscalls break the
> -fno-delayed-branch behavior. I have code like
> 
>    #define _syscall1(type,name,atype,a) \
>    type name(atype a) \
>    { \
> 	   register unsigned long __a0 asm("$4") = (unsigned long) a; \
> 	   register unsigned long __v0 asm("$2"); \
> 	   \
> 	   __asm__ volatile ( \
> 	   ".set\tnoreorder\n\t" \
> 	   "li\t$2, %2\t\t\t# " #name "\n\t" \
> 	   "syscall\n\t" \
> 	   ".set\treorder" \
> 	   : "=&r" (__v0) \
> 	   : "r" (__a0), "i" (__NR_##name) \
> 	   ); \
> 	   \
> 	   return (type) __v0; \
>    }
>    #define __NR_exit 0
>    static inline _syscall1(void,exit , int, code );
> 
> and with the call of exit(...), the delay slots are filled with
> instructions. If I just define a plain function and call that,
> -fno-delayed-branch seems to behave correctly.

I see.  This is not a bug in the compiler.  The ".set reorder"
directive tells the assembler that it should reorder instructions into
branch delay slots when possible.  The compiler just copies the ".set
reorder" directly from the asm statement.  Both the compiler and the
assembler are acting as expected.

You should rewrite your asm statement to not use .set reorder.  Do this instead:
    .set push
    .set noreorder
    ...
    .set pop


> Anyway, I've submitted a bug report at
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28325

I've closed out this bug report.

Ian

Re: -fno-delayed-branch and the bne-instruction on MIPS

[Simon Kagstrom]

At 10 Jul 2006 09:27:19 -0700,
Ian Lance Taylor wrote:
> 
> Simon Kagstrom <simon.kagstrom@bth.se> writes:
> 
> > Unfortunately there was no difference with -Wa,-O0. It does however
> > look like the use of Linux-style syscalls break the
> > -fno-delayed-branch behavior. I have code like
> > 
> >    #define _syscall1(type,name,atype,a) \
> >    type name(atype a) \
> >    { \
> > 	   register unsigned long __a0 asm("$4") = (unsigned long) a; \
> > 	   register unsigned long __v0 asm("$2"); \
> > 	   \
> > 	   __asm__ volatile ( \
> > 	   ".set\tnoreorder\n\t" \
> > 	   "li\t$2, %2\t\t\t# " #name "\n\t" \
> > 	   "syscall\n\t" \
> > 	   ".set\treorder" \
> > 	   : "=&r" (__v0) \
> > 	   : "r" (__a0), "i" (__NR_##name) \
> > 	   ); \
> > 	   \
> > 	   return (type) __v0; \
> >    }
> >    #define __NR_exit 0
> >    static inline _syscall1(void,exit , int, code );
> > 
> > and with the call of exit(...), the delay slots are filled with
> > instructions. If I just define a plain function and call that,
> > -fno-delayed-branch seems to behave correctly.
> 
> I see.  This is not a bug in the compiler.  The ".set reorder"
> directive tells the assembler that it should reorder instructions into
> branch delay slots when possible.  The compiler just copies the ".set
> reorder" directly from the asm statement.  Both the compiler and the
> assembler are acting as expected.

Ah, that explains it. I knew what .set reorder / noreorder does, but
it didn't occur to me that this was how GCC implemented the
-fno-delayed-branch option, but it all makes sense now.

> You should rewrite your asm statement to not use .set reorder.  Do this instead:
>     .set push
>     .set noreorder
>     ...
>     .set pop

Thanks for the help, it works now!

// Simon