[Mono-devel-list] Re: [Mono-devel-list]ProblemwithSystem.Reflection.ConstructorInfo

[Ben Maurer]

Actually, the real reason i suggest the create / dup / dup / store / dup
thingy is because it is the only way that works ;-).

>>> "Ben Maurer" <05mauben at hawken.edu> 03/09/04 10:34 AM >>>
Ok, i need to fix/explain more. What the code should look like is:

// Create array

dup

dup
// store 0

dup
// store 1

// store 2
// store 3

This ensures the stack is the same after as it was in the beginning.

The reason I put the extra dup at the beginnding, rather than doing:
// create
dup
// st 0
dup
// st 1
dup
// st 2
// st 3

is for optimization. Dup creates a local variable. However, if it is
actually duplicating a ldloc, it is translated to a simple variable
load. So doing the dup of the dup should be better than doing tons of
dups on the array creation.

This is just me looking into it without the jit in front of me and
without the time to access all the references i need, so i may be
jumping to conclusions. I'd like to hear input from a jit person (/me
looks at lupus).

-- Ben

>>> "Ben Maurer" <05mauben at hawken.edu> 03/09/04 10:24 AM >>>
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

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

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