[Mono-devel-list] Patch for CONV_I/U handling in mini.c

[Zoltan Varga]

                                                       Hi,

   Feel free to check this in. Also, could you add this test to the
regression tests
for example to basic.cs ? 

                      thanks

                               Zoltan

On Tue, 10 Aug 2004 11:49:43 -0700, Bernie Solomon <bernard at ugs.com> wrote:
> Your reply has made me study things a little closer and
> the case that was failing was because the CONV_I was being
> applied when the top of the stack was STACK_OBJ. This
> resulted from the code below (simplified from
> actual code inside System.String) and is presumably because
> of the inlining of the offset of first character inside a string icall.
> The ovfops_op_map array had no entry for STACK_OBJ
> (i.e it was zero) so it was mishandled. This means the attached
> patch fixes this case by making STACK_OBJ get converted
> like other pointer types.
> 
> Is this a better approach? (My previous patch handled this
> too but with more code). I guess other tables may need checking
> too but I thought I;d check on the approach first.
> 
> Bernie
> 
> using System;
> 
> class Test
> {
>         unsafe void x()
>         {
>                 string tmp = "xxx";
>                 fixed (char* dest = tmp) {
>                         char* destPtr = (char*)dest;
>                         char c = *destPtr;
>                 }
>         }
>         static public void Main()
>         {
>             Test t = new Test();
>             t.x();
> 
> 
>         }
> }
> 
> ----- Original Message -----
> From: "Zoltan Varga" <vargaz at gmail.com>
> To: "Bernie Solomon" <bernard at ugsolutions.com>
> Cc: <mono-devel-list at lists.ximian.com>
> Sent: Tuesday, August 10, 2004 10:18 AM
> Subject: Re: [Mono-devel-list] Patch for CONV_I/U handling in mini.c
> 
> >                                                  Hi,
> >
> >   I fail to see why this is neccesary. CONV_I and friends are already
> > transformed
> > to OP_LCONV_I in type_from_op () if the top of the stack is an int64.
> > OP_LCONV_I is then handled by the rules in inssel-long<32>.brg, so the
> > backend will never see it. If the top of the stack is an int32, then
> CONV_I is
> > passed to the rules in inssel.brg, which either emit a move on 32 bit
> machines,
> > or pass it to the backend on 64 bit machines. So the backend should
> allways
> > emit a widening op. It might be more meaningful to transform CONV_I into
> > OP_ICONV_I in the burg rules, to signify that it is a 32 bit op.
> >
> >                      Zoltan
> >
> > On Fri, 30 Jul 2004 11:10:01 -0700, Bernie Solomon
> > <bernard at ugsolutions.com> wrote:
> > >
> > > I attach a patch to mini.h/c to improve handling of cast to native int
> for
> > > 64 bit machines.
> > > This affects CONV_I and similar opcodes.
> > >
> > > If the type is already the same size as a ptr no instruction is
> generated so
> > > that
> > > for a 64bit machine if a CEE_CONV_I gets through to the code generation
> > > stage (as it does for sparc V9) it must be a 4 to 8 byte widening
> operation.
> > >
> > > I added the STACK_I macro to make this easier to code.
> > >
> > > OK to commit?
> > >
> > > Bernie Solomon
> > >
> > >
> > >
> >
> 
> 
>