[PATCH] D11438: Fix x86_64 fp128 calling convention

[David Li via llvm-commits]

davidxl added a comment.

It seems to me the patch does not use the right approach in SoftenFloatResult and SoftenFloatOperands. The patch tries to workaround the the problem that the softened result does not have the right type (same size integer instead of float type). To workaround the problem, the patch skips 'softening' completely for some opcodes such as BITCAST, SELECT, and as a result, has to change the prototype of SoftenFloatResult and allows operands scanning which should not be necessary if done properly.

It seems to be the right approach is to make sure those variants of SoftenFloatRes_<OPCODE> to return and set the right 'softened' float type for f128. There are two main places that need to be changed: TargetLowering::makeLibCall and BitConvertToInteger by making them f128 aware. Does it make sense?


================
Comment at: lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp:726
@@ +725,3 @@
+  EVT OpVT = N->getOperand(OpNo).getValueType();
+  bool KeepFloat = OpVT.isSimple() && TLI.isTypeLegal(OpVT);
+
----------------
Why is keepFloat computed differently from SoftenFloatResult?

================
Comment at: lib/CodeGen/SelectionDAG/LegalizeTypes.h:381
@@ -378,1 +380,3 @@
     SDValue &SoftenedOp = SoftenedFloats[Op];
+    if (!SoftenedOp.getNode() &&
+        Op.getValueType().isSimple() &&
----------------
If SetSoftenedFloat was called with the right value, then there is no need to do special handling here. This is the reason why I think SoftenFloatResult should not special handling those op code.


http://reviews.llvm.org/D11438