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

[Paolo Molaro]

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