[llvm-commits] [PATCH][Review request] IEEE quad software emulation library call

[Hatanaka, Akira]

I found the changes I made in my previous patches were not correct and some of the test programs failed to compile. So here are the revised patches and the updated test case.

f128-1: Add libcall enums and set default lib call names. Add Call_F128 parameter to
GetFPLibCall.

f128-2: Pass NumOps to LowerCallTo so that OutputArg::IsFixed is set to true if the argument
being passed is not a variable argument.

f128-3: Add array PassArgsInFloatRegs to TargetLowering which is used as a flag that indicates
whether an argument or return value of a certain type should be passed in floating point
registers. If PassArgsInFloatRegs is true for the original type of an argument or return value, the
type of InputArgs or OutputArgs is converted to a floating point type of the same size before it is 
passed to TargetLowering::LowerCall, LowerFormalArguments or LowerReturn.
NumRegistersForVT or RegisterTypeForVT for f128 does not change once it is set in
TargetLowering::computeRegisterProperties(). No bit-casting from i128 to f128 or vice versa is
needed.

f128-4: Changes in constructor of MipsTargetLowering.


I think the first patch consists of mostly mechanical changes and the second one is harmless too.
Is it okay to commit them?

________________________________________
From: Hatanaka, Akira
Sent: Thursday, January 26, 2012 4:17 PM
To: Anton Korobeynikov
Cc: Eli Friedman; baldrick at free.fr; llvm-commits at cs.uiuc.edu
Subject: RE: [llvm-commits] [PATCH][Review request] IEEE quad software emulation library call

I have been thinking about this for a while but haven't been able to come up with a solution that is much better.

Nodes in a DAG is legalized top-down, and f128 nodes have to be transformed to integer type nodes and then expanded into smaller type nodes to make forward progress, so it seems difficult to not legalize operands of nodes that require library calls without making drastic changes in the code. Bitcasting an i128 to f128 is silly, but I think it is a lot simpler.

I have attached another patch which basically takes the same approach but is cleaner than the previous one.
Properties of f128 are set by the target if it needs to have arguments passed in floating point registers:
    setRegisterType(MVT::f128, MVT::f64);
    setNumRegisters(MVT::f128, 2);
    setTypeToTransformTo(MVT::f128, MVT::f128);


If this isn't the preferred way to legalize f128, I can do pure soft-float legalization in LegalizeFloatTypes.cpp, in the same way other floating point types are legalized, and do i128 <-> f128 conversion in MipsSelLowering.cpp, but that would require changes in LowerCall's API.

________________________________________
From: Anton Korobeynikov [anton at korobeynikov.info]
Sent: Wednesday, January 25, 2012 5:46 AM
To: Hatanaka, Akira
Cc: Eli Friedman; baldrick at free.fr; llvm-commits at cs.uiuc.edu
Subject: Re: [llvm-commits] [PATCH][Review request] IEEE quad software emulation library call

Akira,

> Okay, if that doesn't work, I think I will have to legalize f128 during type legalization.
> Is the patch fine as it is now? Or does it need further changes?
I'm still thinking about better approach. It seems silly to legalize
f128 to i128, and try to "recover" from this afterwards.
Maybe we can somehow not legalize arguments to libcalls here... ? And
use the common codegenerator code to do all necessary CC stuff.

Do you have any ideas here?

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University
-------------- next part --------------
A non-text attachment was scrubbed...
Name: f128-1.patch
Type: text/x-patch
Size: 41627 bytes
Desc: f128-1.patch
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120208/bd522b88/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: f128-2.patch
Type: text/x-patch
Size: 959 bytes
Desc: f128-2.patch
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120208/bd522b88/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: f128-3.patch
Type: text/x-patch
Size: 5456 bytes
Desc: f128-3.patch
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120208/bd522b88/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: f128-4.patch
Type: text/x-patch
Size: 736 bytes
Desc: f128-4.patch
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120208/bd522b88/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: f128.ll
Type: application/octet-stream
Size: 8751 bytes
Desc: f128.ll
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120208/bd522b88/attachment.obj>