Question

Is there an attribute I can use to tell the compiler that a method must always be optimized, even if the global /o+ compiler switch is not set?

The reason I ask is because I’m toying with the idea of dynamically creating a method based on the IL code of an existing method; the manipulation I want to do is reasonably easy when the code is optimized, but becomes significantly harder in non-optimized code, because of the extra instructions generated by the compiler.

---

EDIT: more details about the non-optimizations that bother me…

Let’s consider the following implementation of the factorial function:

static long FactorialRec(int n, long acc)
{
    if (n == 0)
        return acc;
    return FactorialRec(n - 1, acc * n);
}

(Note: I know there are better ways to compute the factorial, this is just an example)

The IL generated with optimizations enabled is quite straightforward:

IL_0000:  ldarg.0     
IL_0001:  brtrue.s    IL_0005
IL_0003:  ldarg.1     
IL_0004:  ret         
IL_0005:  ldarg.0     
IL_0006:  ldc.i4.1    
IL_0007:  sub         
IL_0008:  ldarg.1     
IL_0009:  ldarg.0     
IL_000A:  conv.i8     
IL_000B:  mul         
IL_000C:  call        UserQuery.FactorialRec
IL_0011:  ret         

But the unoptimized version is quite different

IL_0000:  nop         
IL_0001:  ldarg.0     
IL_0002:  ldc.i4.0    
IL_0003:  ceq         
IL_0005:  ldc.i4.0    
IL_0006:  ceq         
IL_0008:  stloc.1     
IL_0009:  ldloc.1     
IL_000A:  brtrue.s    IL_0010
IL_000C:  ldarg.1     
IL_000D:  stloc.0     
IL_000E:  br.s        IL_001F
IL_0010:  ldarg.0     
IL_0011:  ldc.i4.1    
IL_0012:  sub         
IL_0013:  ldarg.1     
IL_0014:  ldarg.0     
IL_0015:  conv.i8     
IL_0016:  mul         
IL_0017:  call        UserQuery.FactorialRec
IL_001C:  stloc.0     
IL_001D:  br.s        IL_001F
IL_001F:  ldloc.0     
IL_0020:  ret         

It is designed to have only one exit point, at the end. The value to return is stored in a local variable.

Why is this an issue? I want to dynamically generate a method that includes tail call optimization. The optimized method can easily be modified by adding the tail. prefix before the recursive call, since there nothing after the call except ret. But with the unoptimized version, I’m not so sure… the result of the recursive call is stored in a local variable, then there’s a useless branch that just jumps to the next instruction, the the local variable is loaded and returned. So I have no easy way of checking that the recursive call really is the last instruction, so I can’t be sure that tail call optimization can be applied.

Answer 1

If the method you’ll be using as your template for the dynamic method is relatively simple – and without dependencies on other methods. Then just put it in it’s own assembly and turn on optimization for just that assembly.

As far as the original issue, since MSIL is a stack based language. And the specs guarantee stack state at the ret statement you can be 100% sure that you can add a tail prefix without issue. However, it’s also unlikely to actually add any benefit as I haven’t really seen the JIT use the tail prefix to actually optimize the finally jitted code.