16

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.

Thomas Levesque
  • 286,951
  • 70
  • 623
  • 758
  • 1
    AFAIK, no - that is not possible – Marc Gravell Mar 13 '12 at 10:56
  • 1
    The JIT compiler will always optimize every method. – Steven Mar 13 '12 at 11:01
  • @Steven, not if you tell it not to (e.g. with the `NoOptimization` flag in the `MethodImplAttribute`). But anyway, my question is about the compiler optimizations, not the JIT optimization, since I'm interested in the IL code that is generated. – Thomas Levesque Mar 13 '12 at 11:17
  • 1
    I'd like to see you document the exact kind of IL you are having a problem with. Turning on optimization in the C# compiler has little effect afaik, it just omits the NOP opcodes that the compiler emits to make debugging easier. The only practical solution I can think of is to move the code into a separate assembly, one that you then simply can build with optimization enabled. – Hans Passant Mar 13 '12 at 11:33
  • @HansPassant, it's not just the `nop` opcodes (I could easily ignore those), the flow of the IL code is actually different. I updated my question to add more details. – Thomas Levesque Mar 13 '12 at 14:13
  • That sounds like it could be messy - if you're ever in a situation when you need to debug the original method (and so will disable the "optimize always" feature, if you ever find it), but where this "convert an existing method" functionality must also work, you're doomed. – Damien_The_Unbeliever Mar 13 '12 at 15:48
  • It seems to me you can't tail call optimize the code compiled without /optimize because the call really isn't the last instruction, so your add-on optimizer should leave the code alone. – NetMage Mar 14 '12 at 23:35
  • @NetMage, yet, but what if the code *can't* execute without tail call optimization? i.e. if the recursion is too deep, it will blow the stack – Thomas Levesque Mar 14 '12 at 23:49

3 Answers3

2

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.

Paul Alexander
  • 31,970
  • 14
  • 96
  • 151
0

Is there anyway you could generate the original method code dynamically using Microsoft.CSharp.CSharpCodeProvider?

If you control the method compilation, you can set the options when you call the compiler using CompilerOptions.

NetMage
  • 26,163
  • 3
  • 34
  • 55
0

You can never be sure that you get tail call optimization, as long as you use C#.

In particular even with call ... ret the JITter does not guarantee a tail call. So IMO C# code relying on tail call optimization(to avoid stack-overflow) is simply broken. In C# tail call optimization is purely a performance optimization.

Use a language where tail calls are emitted reliably, or rewrite your method so that it doesn't need tail calls.

CodesInChaos
  • 106,488
  • 23
  • 218
  • 262
  • I know C# isn't suitable for tail calls, I was just doing a proof of concept... don't worry, I don't intend to use this in production code ;) – Thomas Levesque Mar 14 '12 at 23:52