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

[Laurent Morichetti]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20031105/48e977c5/attachment.html