[Mono-dev] CIL optimizer
jeroen at sumatra.nl
Sun Oct 3 03:30:39 EDT 2010
I'm currently working on adding a simple CIL peephole optimization phase to ikvmc. The primary reason is to reduce file size, because as Rodrigo pointed out the JIT will also do most of these optimizations, but I believe that file size is important too.
Some of the optimizations I'm doing could very well be done by a general optimizer (in theory*), but others are IKVM specific, so I don't quite know where I stand on a stand-alone CIL optimizer.
* In practice you can't do any CIL rewriting for ikvmc generated code if you want the stack trace line numbers to continue to make sense, because the CIL offset to source line numbers are stored in a custom attribute attached to the method.
> -----Original Message-----
> From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-
> bounces at lists.ximian.com] On Behalf Of Justin Malcolm
> Sent: Saturday, October 02, 2010 8:24 PM
> To: mono-devel-list at lists.ximian.com
> Subject: Re: [Mono-dev] CIL optimizer
> Thank you for the reply Rodrigo,
> Do you mean that there is not much room for optimization of the output
> from 'mcs' or just of CIL in general? I have heard that the Microsoft
> C++ compiler output better code than the C# one did (at least at some
> point) so I assumed that CIL efficiency mattered.
> I was thinking that a generic CIL optimizer would make it possible for
> compiler writers (and others) to worry less about optimization. I am
> writing a compiler myself and I was thinking of keeping the compiler
> optimization stupid and implementing a stand-alone CIL optimizer to go
> with it. That is why I wanted to know if anybody else had done any work
> on it.
> I know one thing, my current compiler puts out some pretty bad CIL. For
> example, compiling 5+4*3-6/3 in my compiler results in a bunch of 'i4'
> literals along with 'mul', 'add', 'sub', and 'div' instructions.
> Clearly this could be better. I figured, why do it in every compiler
> when I could just write a generic optimizer instead.
> I guess I do not really know what optimizations .NET and Mono do at the
> JIT level so I am not sure how the CIL affects the quality of the
> machine code that actually gets executed. Do things like dead code
> elimination, constant propagation, loop unrolling, conversion avoidance,
> and changing things like "idc.i4" to "idc.i4.s" affect the final result
> at all or just the JIT time?
> It sounds like you are implying that the JIT manages pretty well even
> when you feed it inefficient CIL. Then again, your instrumentation
> comment makes me wonder if I have that right. If you could elaborate, I
> would appreciate knowing if I would be wasting my time to go down this
> If you were going to optimize the CIL, where would you expect to get a
> return on your efforts?
> I did not expect that anything had been done but I guess there was no
> harm in asking. If I get there myself, I will let you know.
> On 2 October 2010 07:26, Rodrigo Kumpera <kumpera at gmail.com> wrote:
> Nothing happened on this front for two reasons.
> First that nobody had the time for it. It's a major undertaking.
> Second, not one is sure that it will yield any improvements at all.
> Given CIL
> is a quite high level format with some rigid structure
> requirements, there isn't
> much room for optimization - at least at glance.
> It has been suggested that producing a different format, that is
> more amendable
> for optimization would allow for better results but, again, it's an
> even harder task
> with the same level of uncertainty.
> A CIL optimizer has one valid use case thou, that is to optimize
> code that has
> been instrumented. This would avoid the instrumentation writer
> having to care
> about emitting efficient CIL bytecode.
> On Sat, Oct 2, 2010 at 4:54 AM, jmalcolm <malcolm.justin at gmail.com>
> I remember reading a very long while back that there might be
> a plan to
> create a generic CIL optimizer. I understood this to mean
> CIL in and better
> CIL out.
> Did anything ever happen with this? Is there any code
> anywhere I can dig
> View this message in context:
> Sent from the Mono - Dev mailing list archive at Nabble.com.
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list