On 15/07/2013 1:03 PM, Jonathan S. Shapiro wrote: > Obviously there are differences between the mono and the M$ > infrastructure, but I'm saying something else entirely. I'm not clear > whether the .NET /API/ for back-end access provides access to the > optimizer, or just the low-level emitter.
There is no direct access to the optimizer in CIL. The best you can do is provide some "hints" that the implementation is free to ignore, like the .tailcall opcode. The only exceptions are independent opcodes for operations that do/do not overflow, and the readonly instruction which elides a runtime type check during array access [1]. Most of the optimizations I've ended up implementing depend upon using structs as function type parameters, which forces the code generation of custom code for each parameter type passed in. This can take you quite far, for instance, by allowing you to declare a generic arithmetic interface that generates custom code for all primitives [2], but it's not clear the degree of optimizer access you're looking for. Sandro [1] http://msdn.microsoft.com/en-us/library/system.reflection.emit.opcodes.readonly.aspx [2] For instance: interface IArith<T> where T : struct, IArith<T> { T Int(int i); T Add(T left, T right); ... } ... T Increment<T>(T value) where T : struct, IArith<T> { return default(T).Int(1).Add(value); } _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
