I'm not particularly looking for optimizer access. I'm just trying to understand whether, in the CLR case, I'm talking to the front end or the back end of a conventional optimization chain. From what you say, the answer is "the back end".
Thanks On Mon, Jul 15, 2013 at 11:38 AM, Sandro Magi <[email protected]>wrote: > 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 > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
