MSIL Optimizer?

  • Thread starter Thread starter cody
  • Start date Start date
C

cody

is there any tool which can optimize msil? for example:

if (a is MyType)
{
MyType mt = (MyType)a
}

could turn into:

MyType mt = mt as MyType ;
if (mt!=null)
{
}

Maybe there are much more such situations.

I know that the jitter *could* do such Optimisations, but does it?
 
is there any tool which can optimize msil? for example:
if (a is MyType)
{
MyType mt = (MyType)a
}
could turn into:
MyType mt = mt as MyType ;
if (mt!=null)
{
}
Maybe there are much more such situations.
Click to expand...

yes... same tool that can make ugly woman beautiful... :)
there is no optimizer for poorly written code...
 
is there any tool which can optimize msil? for example:
yes... same tool that can make ugly woman beautiful... :)
there is no optimizer for poorly written code...
Click to expand...


1. this is no poorly written code
2. it would simply be possible to make such a tool
3. the question is: does such a tool exist?
 
Really?
Click to expand...

I suspect it wouldn't be *very* hard to write something which detected
the code that the C# compiler emitted for

if (localVariable is SomeType)
{
anyVariable = (SomeType)localVariable;
}

and converted it to the appropriate "as" form.

(Whether or not it should deal with non-local variables is a slightly
different matter - it would depend on the volatility of the variable,
for a start.)

Whether or not it would be worth it would be an entirely different
matter. Possibly the C# compiler could be tweaked to optimise the code
itself at that stage - or emit a warning to suggest the more optimal
code?
 
Truthfully the only thing that needs to be IL optimized at this stage of the C#
compiler is stack local usage. They don't share stack locals for nested
elements, when they probably should, since IL has a method for aliasing
nested locals to be re-used. For instance:

for(int i = 0; i < 10; i++) {}
for(int i = 0; i < 10; i++) {}
for(int i = 0; i < 10; i++) {}

How many locals does that produce? 3 of them, though you'd only think
it would produce one. IL has something called slot aliasing, so they could
refer to i as V_0, V_1, and V_2, but all three of these variables would
share the same stack slot.

This is only a code-size enhancement, but it produces decent results. As for
the 'as' enhancement. That type of layout is easy to detect. Changing it
really
doesn't produce that much of an enhancement though, and you'd have to
special case your detection logic so that it didn't try to convert value type
instances of the is/casting pattern. Of course, the IL for a value type versus
object type casting looks different (castclass versus unbox), so that shouldn't
be a big issue.

I can't find my blog entry on the stack local enhancement, but it is in there
somewhere
under the performance category if anyone is interested.

--
Justin Rogers
DigiTec Web Consultants, LLC.
Blog: http://weblogs.asp.net/justin_rogers
 
I suspect it wouldn't be *very* hard to write something which detected
the code that the C# compiler emitted for
Click to expand...
if (localVariable is SomeType)
{
anyVariable = (SomeType)localVariable;
}
Click to expand...
and converted it to the appropriate "as" form.
Click to expand...


really?
that means that compiler should check every possible path
of actions in program to ensure that this IS a form... when
someone uses object like this, I presume that he will be
using different objects and in that case optimization is in
*very-almost imposible* hard.

--

Pozdrav,
Josip Medved, MCSD
http://www.jmedved.com

All given above is stated IMHO.
 
Josip Medved said:
really?
that means that compiler should check every possible path
of actions in program to ensure that this IS a form...
Click to expand...

No, not at all.
when someone uses object like this, I presume that he will be
using different objects and in that case optimization is in
*very-almost imposible* hard.
Click to expand...

It wouldn't need to test that at all. It would merely need to convert:

if (localVariable is SomeType)
{
anyVariable = (SomeType)localVariable;
}

into

SomeType tmp = localVariable as SomeType;
if (tmp != null)
{
anyVariable = tmp;
}

It doesn't need to keep track of anything other than other than
spotting the above pattern. It doesn't need to work out whether or not
the object is an instance of the given type - the "as" operator does
that instead, just more efficiently.
 
Back
Top