[Mono-devel-list] Problem withSystem.Reflection.ConstructorInfo

[Ben Maurer]

Ok, so just a follow up on the dup vs variable thing. It looks like
doing a dup will get the same code emitted but with the same or fewer
bytes of IL code. What I would do is something like:

// push array to stack
dup // temp store

dup // load array
// set element 0

dup // load array
// set element 1

dup // load array
// set element 2

Compare this to the best case, which is:

// create
stloc.0

ldloc.0
// set elem 0

ldloc.0
// set elem 1

ldloc.0
// set elem 2

In both cases, there are 4 bytes of IL code in the body. However, in the
second, we have to declare the variable in the header. Also, if you are
not able to use the super-short ldloc.x code, you will come out at a
loss in the body, because you will need to use 8 bytes of IL code.

>>> "Ben Maurer" <05mauben at hawken.edu> 03/09/04 09:53 AM >>>
mcs is a great procrastination tool :-).

Your patch looks pretty nice. However, you should make a test case for
mcs/tests. There are alot of cases here, so you may need more than one.

Also, miguel will insist on a changelog :-).

wrt to your performance questions:

I think that initing null elements is basically a nop. If you do new
Object [5], all the elements are init'd to null. So, I think that the
init code there is pointless. Am pretty sure it can be safely removed.

using dup will probably not result in any perf increase. As I understand
it, it is basically just creating a temp variable inside the jit.
However, you may be able to reduce the size of the IL code. For example,
if you are doing

// create array
stloc.s 6

ldloc.s 6
// store element 1

ldloc.s 6
// store 2
...

The ldloc.s instructions are going to be 2 bytes (I think, i know it is
> 1), while the dup will be a single byte. So you would save in IL code
size. I would probably go with the dup path here, as performance is not
an issue (think about how long it takes to create the array ;-), while
code size could possibly be helped. However, maybe others have comments.

>>> Joshua Tauberer <tauberer at for.net> 03/08/04 20:26 PM >>>
So I procrastinated from doing school work by tracking down this bug...

I just got Ivan Hamilton's email, but since I have my email ready to go,

I'll send it anyway. :)  Plus, I have a slightly different take on 
fixing the bug, although I think Ivan's fix is just as good.

Etienne Boucher wrote:
> The problem seems to be with creating an array 
> from an array initilizer list of more than 6 elements.

The problem was in creating any reference-type array (except string and 
object) with more than 6 nulls.  Nulls, being a type of constant (and 
the only constant that can appear in these reference type arrays), 
tricked mcs into thinking the array could be initialized from a static 
field of values, which mcs would only do if there were more than 6
values.

Attached is a patch that I can commit if the appropriate people think 
it's ok.

While I was looking at this, two possible improvements to array creation

came to mind.  Do null elements of arrays need to be initialized?  The 
CIL specs don't seem to say, which I guess means yes.  (Though numeric 
elements are initialized to zero.)  The other thing is that filling in 
the array elements uses a local variable to hold the array while it's 
being created.  Is there any performance boost to be gained by using 
dup's instead of ldloc's?

-- 
- Joshua Tauberer

http://taubz.for.net

** Nothing Unreal Exists **



_______________________________________________
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list