I'm getting some problems because it seems that the compiler is treating "floor" differently from other math library functions like "sin". The Args and RetVal have the parameter and return types marked as void. For mips16, it's important that I be able to know the original signature for floating point functions. In some cases, need to create calls to helper functions based on the signatures. In newer code I've written, I've actually moved this logica to an IR pass and in that case I know for sure. But this part of the code is in ISelLowering code and I rely on getting the proper signature information. I'm looking at llvm now to see how this is occurring but maybe someone just knows. Tia. Reed
Here is a test case:
extern double floor(double);
extern double floor_(double);
double x = 1.5;
double y, y_;
void foo() {
double y = floor(x);
double y_ = floor_(x);
}
If I compile this for Mips16, it calls the proper helper function for
floor_ but not for floor, because the signature for floor in callee info
is wrong. Args[0] = void RetTy = void
/local/llvmpb_config/install/bin/clang -target mipsel-linux-gnu floor1.c
-o floor1.s -mips16 -S -fPIC
.....
lw $3, %got(x)($2)
lw $4, 0($3)
lw $5, 4($3)
lw $6, %call16(floor)($2)
move $25, $6
move $gp, $2
sw $2, 20 ( $16 );
sw $3, 16 ( $16 );
jalrc $6
sw $3, 36($16)
sw $2, 32($16)
lw $2, 16 ( $16 );
lw $5, 4($2)
lw $4, 0($2)
lw $3, 20 ( $16 );
lw $2, %call16(floor_)($3)
lw $6, %got(__mips16_call_stub_df_2)($3)
move $gp, $3
jalrc $6
....
On 07/26/2013 03:33 PM, reed kotler wrote:> I'm getting some problems because it seems that the compiler is
treating
> "floor" differently from other math library functions like
"sin".
>
> The Args and RetVal have the parameter and return types marked as void.
>
> For mips16, it's important that I be able to know the original
signature
> for floating point functions.
>
> In some cases, need to create calls to helper functions based on the
> signatures.
>
> In newer code I've written, I've actually moved this logica to an
IR
> pass and in that case I know for sure.
>
> But this part of the code is in ISelLowering code and I rely on getting
> the proper signature information.
>
> I'm looking at llvm now to see how this is occurring but maybe someone
> just knows.
>
> Tia.
>
> Reed
Consider
include <math.h>
float y = 1.0;
int main() {
float x = sin(y);
printf("%e \n", x);
}
Sin works.
/local/llvmpb_config/install/bin/clang -target mipsel-linux-gnu sin1.c
-o sin1.s -lm -mips16 -S -fPIC
....
lw $3, %got(y)($2)
lw $4, 0($3)
lw $3, %call16(__mips16_extendsfdf2)($2)
move $25, $3
move $gp, $2
sw $2, 36 ( $16 );
sw $3, 32 ( $16 );
jalrc $3
lw $4, 36 ( $16 );
lw $5, %call16(sin)($4)
lw $6, %got(__mips16_call_stub_df_2)($4)
sw $2, 28 ( $16 );
move $2, $5
lw $4, 28 ( $16 );
move $5, $3
lw $3, 36 ( $16 );
move $gp, $3
jalrc $6
....
On 07/26/2013 03:59 PM, Reed Kotler wrote:>
> Here is a test case:
>
> extern double floor(double);
> extern double floor_(double);
>
> double x = 1.5;
> double y, y_;
>
> void foo() {
>
> double y = floor(x);
> double y_ = floor_(x);
> }
>
>
> If I compile this for Mips16, it calls the proper helper function for
> floor_ but not for floor, because the signature for floor in callee info
> is wrong. Args[0] = void RetTy = void
>
> /local/llvmpb_config/install/bin/clang -target mipsel-linux-gnu floor1.c
> -o floor1.s -mips16 -S -fPIC
>
> .....
> lw $3, %got(x)($2)
> lw $4, 0($3)
> lw $5, 4($3)
> lw $6, %call16(floor)($2)
> move $25, $6
> move $gp, $2
> sw $2, 20 ( $16 );
> sw $3, 16 ( $16 );
> jalrc $6
> sw $3, 36($16)
> sw $2, 32($16)
> lw $2, 16 ( $16 );
> lw $5, 4($2)
> lw $4, 0($2)
> lw $3, 20 ( $16 );
> lw $2, %call16(floor_)($3)
> lw $6, %got(__mips16_call_stub_df_2)($3)
> move $gp, $3
> jalrc $6
>
> ....
>
>
> On 07/26/2013 03:33 PM, reed kotler wrote:
>> I'm getting some problems because it seems that the compiler is
treating
>> "floor" differently from other math library functions like
"sin".
>>
>> The Args and RetVal have the parameter and return types marked as void.
>>
>> For mips16, it's important that I be able to know the original
signature
>> for floating point functions.
>>
>> In some cases, need to create calls to helper functions based on the
>> signatures.
>>
>> In newer code I've written, I've actually moved this logica to
an IR
>> pass and in that case I know for sure.
>>
>> But this part of the code is in ISelLowering code and I rely on getting
>> the proper signature information.
>>
>> I'm looking at llvm now to see how this is occurring but maybe
someone
>> just knows.
>>
>> Tia.
>>
>> Reed