[LLVMdev] soft float signature problem

[Reed Kotler]

I came up with a decent workaround to this problem but it still would be 
nice to fix it as described below.

On 01/22/2013 02:20 PM, Reed Kotler wrote:
> What happens here is that the code that is doing the "softening",
> generates a libcall
>
> On closer inspection, llvm is doing half of this correctly.
>
> The signature for the soft float function for extending a float to
> double is of the form:
>
> i64 xxx_extendsfdf2(float);
>
> But it should be
>
> i64 xxx_extendsfdf2(i32)
>
> This particular paradigm is duplicated many times in the the float type
> lowering.
>
> I'm not sure exactly how to change this and what effect if any that it
> might have.
>
> thoughts?
>
> In my case for mips16, it's important that I know the proper function
> signature, otherwise I'll generate an unnecessary helper function call.
>
> tia.
>
> Reed
>
> On 01/20/2013 06:28 AM, Reed Kotler wrote:
>> I'm implementing this unusual gcc form of mips16 hard float.
>>
>> I ran into one unexpected wrinkle. It effects efficiency as opposed to
>> correctness but I'd like to figure out the best way to resolve it.
>>
>> The signatures for the libcall routines have floating point arguments
>> in  at least some situations. I have not fully examined
>> if it's all of them. So in callinfo while I'm lowering the call, the
>> first argument for example will appear to be a float.
>>
>> For sure in the following situation:
>>
>> float f;
>> ...
>> printf("%f \n", f);
>>
>> So it generates a libcall to widen f to double.
>>
>> long int XXX_extendsfdf2(float);
>>
>> The problem for me is that the parameter should be int since this is a
>> soft float routine. Probably nobody ever looks at this argument type in
>> this situation.
>>
>> So I think this should look like:
>> long int XXX_extendsfdf2(int);
>>
>> In my case the routine is called __mips16_extendsfdf2 .
>>
>> When I see the first parameter as float, I think that I need to generate
>> a mips16 helper function. This is because in the abi that parameter
>> would be passed in a floating point argument register but this is not
>> possible in mips16 mode since there are no floating point instructions.
>>
>> For interoperability between mips16 and mips32, when I see an external
>> call, I don't know if it's mips16 or mips32, so I automatically must
>> generate a helper function so that the call works correctly whether the
>> extern is in a module compiled as mips16 or mips32.
>>
>> What I was not expecting is to see such a signature from a routine which
>> is already a routine generated for soft float.
>>
>> So I'm generating an unneeded call to a helper function.
>>
>> I could try and filter it out based on the name of the routine being
>> called but it seems that this is just the result of a mistake in target
>> independent code.