llvm dev - Apr 2013 - [LLVMdev] interesting IR problem related to mips 16

When a mips16 wants to return a floating point value, it's at a quandary 
in mixed mode programs (having both mips16 and mips32 code).

float foo() {
   return 1.0;
}

Mips16 code is compiled in soft float, with there being an options to 
have the emulation library be written in mips32 and use floating point 
instructions in those mips32 support functions (if the machine supports 
floating point) but in any case, Mips16 is always using soft float (this 
optional emulation library you get with -hard-float for mips16 and is 
the default).

So if the code returns a float, it will get converted into returning an 
integer which in mips abi means it will be returned in an integer register.

so it becomes:
int foo() {
   return int_representation(1.0);
}

However, mips32 code calling this is compiled without soft float and 
does not know anything about this. and will expect the return result to 
be in F0.

So gcc will generate a call to a helper function that moves the V0 
integer return register, to F0 (the floating point return register) 
before returning.

further transformation:
int foo() {
   helper_function(1.0);
   return int_representation(1.0);
}

So now, no matter whether a mips16 or mips32 function calls foo, it will 
be able to retrieve the return result.

The problem is that the helper_function has an important side effect, 
i.e. it sets the value of f0 but this is not reflected in the IR.

so if foo had been changed to:

float x, y, z;
float foo() {
   float x = y + z;
   return 1.0;
}

now if we convert to

float x,y,z;
float foo() {
   softfloat(x=y+z)
   helper_function(1.0);
   return int_representation(1.0);
}

During optimization , this could get converted to:
float x,y,z;
float foo() {
   helper_function(1.0);
   softfloat(x=y+z)
   return int_representation(1.0);
}


Because there is no dependency preventing this.

now the side effect of the helper function will be destroyed by the 
execution of x = y + z;

There is no "glue" between the call to the helper function and return 
statement.

Any ideas how to do what I want in the IR as opposed to the DAG?

TIA.

Reed

Hi Reed,

On 18/04/13 01:11, reed kotler wrote:
> When a mips16 wants to return a floating point value, it's at a
quandary in
> mixed mode programs (having both mips16 and mips32 code).
>
> float foo() {
>    return 1.0;
> }
>
> Mips16 code is compiled in soft float, with there being an options to have
the
> emulation library be written in mips32 and use floating point instructions
in
> those mips32 support functions (if the machine supports floating point) but
in
> any case, Mips16 is always using soft float (this optional emulation
library you
> get with -hard-float for mips16 and is the default).
>
> So if the code returns a float, it will get converted into returning an
integer
> which in mips abi means it will be returned in an integer register.
>
> so it becomes:
> int foo() {
>    return int_representation(1.0);
> }
>
> However, mips32 code calling this is compiled without soft float and does
not
> know anything about this. and will expect the return result to be in F0.
>
> So gcc will generate a call to a helper function that moves the V0 integer
> return register, to F0 (the floating point return register) before
returning.
>
> further transformation:
> int foo() {
>    helper_function(1.0);
>    return int_representation(1.0);
> }
>
> So now, no matter whether a mips16 or mips32 function calls foo, it will be
able
> to retrieve the return result.
>
> The problem is that the helper_function has an important side effect, i.e.
it
> sets the value of f0 but this is not reflected in the IR.
at the IR level, can't you just use "float"?  I mean, foo can be
declared as:

   float foo() { ... }

The fact that float gets morphed into i32 is entirely a codegen detail, so
should be handled in codegen.

Ciao, Duncan.
>
> so if foo had been changed to:
>
> float x, y, z;
> float foo() {
>    float x = y + z;
>    return 1.0;
> }
>
> now if we convert to
>
> float x,y,z;
> float foo() {
>    softfloat(x=y+z)
>    helper_function(1.0);
>    return int_representation(1.0);
> }
>
> During optimization , this could get converted to:
> float x,y,z;
> float foo() {
>    helper_function(1.0);
>    softfloat(x=y+z)
>    return int_representation(1.0);
> }
>
>
> Because there is no dependency preventing this.
>
> now the side effect of the helper function will be destroyed by the
execution of
> x = y + z;
>
> There is no "glue" between the call to the helper function and
return statement.
>
> Any ideas how to do what I want in the IR as opposed to the DAG?
>
> TIA.
>
> Reed
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev