patch for problem when mips16 hard float is linked as c++

[reed kotler]

On 02/14/2014 03:35 AM, Richard Sandiford wrote:
> reed kotler <rkotler at mips.com> writes:
>> On 02/12/2014 10:59 AM, Rafael Espíndola wrote:
>>> On 12 February 2014 13:03, reed kotler <rkotler at mips.com> wrote:
>>>> This patch has been rewritten to not use output raw text in MipsAsmPrinter
>>>> and so is being sent out to the list
>>>> before actual commit to make sure there are no further objections.
>>> Thanks!
>>>
>>>> This patch has two main functions:
>>>>
>>>> 1) Fix a specific bug when certain conversion functions are called in a
>>>> program compiled as mips16 with hard float and
>>>> the program is linked as c++. There are two libraries that are reversed in
>>>> the link order with gcc/g++ and clang/clang++ for
>>>> mips16 in this case and the proper stubs will then not be called. These
>>>> stubs are normally handled in the Mips16HardFloat pass
>>>> but in this case we don't know at that time that we need to generate the
>>>> stubs. This must all be handled later in code generation
>>>> and we have moved this functionality to MipsAsmPrinter. When linked as C
>>>> (gcc or clang) the proper stubs are linked in from libc.
>>> This is strange, but as long as it is local to the Mips backend that
>>> is probably fine. Can you share a bit more what the issue is? What
>>> stub that needs to be generated but currently is not? When can you
>>> find out that it is needed?
>> Richard Sandiford  who is on this list now (and is the supreme gcc Mips
>> expert) can explain this latest wrinkle more fully.
> I might have misunderstood, but it sounded like Rafael's question was more:
> why is __floatdidf a special case?  And the answer is that it isn't really.
> At least it isn't in GCC.  __floatdidf has the normal interface for a function
> with its prototype and GCC handles it like calls to any other function.
> I haven't looked at the LLVM code to see why LLVM needs to treat it as
> a special case.
>
> The link order difference that Reed mentions is just that libgcc_s.so
> gets linked before libgcc.a for g++ but not for gcc, so an object linked
> by g++ will resolve __floatdidf dynamically while an object linked by gcc
> will resolve it statically.  If libgcc.a is compiled as MIPS16 then the
> linker can resolve the __floatdidf call directly to the MIPS16 implementation,
> so a missing stub wouldn't be noticed.
For mips16 hard float, we are running llvm with soft float "on" in the 
target independent part of the code.

I would like to revisit some things more at a later time but in general 
the soft float in llvm does not
seem to consistently preserve the signature information of function 
calls. It only has enough for normal code
generation but if some float parameter has been changed to integer 
because it's soft float, I can't
always know that anymore.

I do most of my work from the higher level IR (bitcodel, llvm assembler).

But functions like floatdidf do not appear in the higher level IR so I 
do not see them.
I need to have a list of such compiler inserted functions and what their 
signatures are (return type and parameter profile).

This list may not be exhaustive:
const FuncNameSignature PredefinedFuncs[] = {
   { "__floatdidf", { NoSig, DRet } },
   { "__floatdisf", { NoSig, FRet } },
   { "__floatundidf", { NoSig, DRet } },
   { "__fixsfdi", { FSig, NoFPRet } },
   { "__fixunsdfsi", { DSig, NoFPRet } },
   { "__fixunsdfdi", { DSig, NoFPRet } },
   { "__fixdfdi", { DSig, NoFPRet } },
   { "__fixunssfsi", { FSig, NoFPRet } },
   { "__fixunssfdi", { FSig, NoFPRet } },
   { "__floatundisf", { NoSig, FRet } },
   { 0, { NoSig, NoFPRet } }
};

//
It would be better to just figure this out from the lower level function 
signature information that is available
during ISelLowering.

This part of the Mips port 16 port needs to be cleaned up and I have 
some bugs I've filed against myself
at Mips/Imagination to do this now that I better understand the whole 
picture.

So the libc routines for _floatdidf are compiled as Mips16 so they have 
signatures because in that case, they
are just normal functions and the signatures are visible in the bitcode 
level IR.


Reed

I do not have the time at this exact moment to dig in and totally 
understand all that is happening during soft float
and how
> Thanks,
> Richard
>