Why does the compiler create an instruction that seems to do nothing when returning a string from a method?

Question

I was having a look at the IL generated for a very simple method because I want to do a small bit of reflection emitting myself and I came across something that is mentioned in the comments in this question (but was not the question):Using Br_S OpCode to point to next instruction using Reflection.Emit.Label and nobody answered it and I am wondering about it. so...

If I have a method like this:

    public string Test()
    {            
        return "hello";
    }

and then I run ILDASM on it I see the IL is this:

.method public hidebysig instance string 
        Test() cil managed
{
  // Code size       11 (0xb)
  .maxstack  1
  .locals init ([0] string CS$1$0000)
  IL_0000:  nop
  IL_0001:  ldstr      "hello"
  IL_0006:  stloc.0
  IL_0007:  br.s       IL_0009
  IL_0009:  ldloc.0
  IL_000a:  ret
}

The part that I find curious is:

  IL_0007:  br.s       IL_0009
  IL_0009:  ldloc.0

The first line is doing an Unconditional Transfer to the second line. What is the reason for this operation, doesn't it do nothing?

EDIT

It seems my question was phrased badly as there is some confusion over what I wanted to know. The last sentence should maybe be something like this:

What is the reason that the compiler has output this unconditional transfer statement when it seems to be serving no purpose?

UPDATE

The suggestion that it was for a breakpoint made me think to try and compile this in Release mode and sure enough the part that I am interested in vanished and the IL became just this (which is why I jumped the gun and thought that the breakpoint answer was the reason):

.method public hidebysig instance string 
        Test() cil managed
{
  // Code size       6 (0x6)
  .maxstack  8
  IL_0000:  ldstr      "hello"
  IL_0005:  ret
} 

The question of "why is it there" still plays on my mind though - if it is not the way the compiler always works and it is not for some useful debugging reason (like having somewhere to place a breakpoint) why have it at all?

I guess the answer is probably: "just the way it has been made, no solid reason, and it doesn't really matter because the JIT will sort it all out nicely in the end."

I wish I'd not asked this now, this is going to ruin my acceptance percentage!! :-)

Answer 1

The first of the two instructions is part of the standard code for the return statement, the second instruction is part of the boilerplate code for the method.

The return statement puts the return value in a local variable, then it jumps to the exit point of the method:

IL_0001:  ldstr      "hello"
IL_0006:  stloc.0
IL_0007:  br.s       IL_0009

The boilerplate code of the method gets the return value from the local variable and then exits from the method:

IL_0009:  ldloc.0
IL_000a:  ret

In the IL code that the compiler creates, a method always have a single exit point. That's why the return statement jumps to that location instead of just exiting the function directly. The code for the return statement is always the same, so there is always a branch even if it jumps to the next instruction.

The compiler often produces IL code that looks inefficient, because the JIT compiler optimises the code. The compiler produces unoptimised, simple and predictable code which is easier for the JIT compiler to optimise.