[Mono-devel-list] incorrect code generated by mcs

[Bernie Solomon]

I think Laurent is right: from the spec on stloc

The stloc indx instruction pops the top value off the evalution stack and
moves it into local variable number indx (see Partition I_alink_partitionI),
where local variables are numbered 0 onwards. The type of value must match
the type of the local variable as specified in the current method's locals
signature.

Actually I recall seeing something a little similar where both csc & mcs
generated a 'dup' to effectively get from a int32 to a nati with no
conversion. I can't recall the input code at the moment. Though there is a
bit of a hack in the interpreter to try and manage this. When I get time
I'll try and work out the offending code.

Bernie

----- Original Message ----- 
From: "Laurent Morichetti" <l_m at pacbell.net>
To: <mono-devel-list at ximian.com>
Sent: Wednesday, November 05, 2003 4:19 AM
Subject: Re: [Mono-devel-list] incorrect code generated by mcs


> I don't have the spec with me right now but I thought that for stloc the
> types had to match. I could be wrong though :)
> -Laurent
>
> Paolo Molaro <lupus at ximian.com> wrote:
>
> On 11/04/03 Laurent Morichetti wrote:
> > I'm trying to get mini to work on 64b and ran accross this problem:
> >
> > for 'int i = array.Length;' mcs generates:
> > ldlen
> > stloc.0
> >
> > it really should generate:
> > ldlen
> > conv.i4
> > stloc.0
> >
> > loc0 is of type int32 and my modified mini cannot match 'ldind.i4
> (regvar) (ldlen (...))'. (cannot store a nati into an int32)
> >
> > I haven't looked at mcs much and don't know where to start to solve
> that problem. Can someone take a look at it.
>
> While the change to mcs is harmless (indeed, csc generates the conv.i4
> instruction as well and on x86 it's removed by the optimizer),
> there is a more general solution that I think should be implemented in
> the JIT. There is a similar case explained in partition III in the
> 'Implicit Argument Coercion' paragraph.
> When a signature requires a int32, if the eval stack contains a native
> int, it is implictly converted (as if a conv.i4 was inserted).
> That is basically the same case as storing a value from the eval stack
> to a local variable.
> If you think about it, the same happens when a double (on the eval
> stack) is stored in a float variable: there is no need to add an
> explicit conversion in IL code: the JIT does it automatically (because
> the cpu has a specific instruction for it: if it didn't we'd have to
> insert an explicit conversion opcode in that case, too).
> So, in the handful places where such an implicit conversion can/should
> happen, we need to add a check and insert an explicit conversion for
> platforms that need it (like in this case for 64 bit architectures).
>
> lupus
>
> -- 
> -----------------------------------------------------------------
> lupus at debian.org debian/rules
> lupus at ximian.com Monkeys do it better
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>