[PATCH] D11438: Fix x86_64 fp128 calling convention

Chih-Hung Hsieh via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 10 17:17:12 PST 2015


chh marked an inline comment as done.

================
Comment at: lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp:68
@@ +67,3 @@
+  if (LegalInHWReg)
+    switch (N->getOpcode()) {
+      case ISD::BITCAST:
----------------
David,

Before my patch, DAGTypeLegalizer::run's loop over results always
(1) goto NodeDone with a changed (new) node, or
(2) goto ScanOperands without changed node,
    for the TargetLowering::TypeLegal case.
All SoftenFloatRes_* functions made new nodes of integer types.

For x86_64 fp128, we really don't want to change the f128 type so that instruction selection can be correct or more efficient based on f128 type instead of i128.
For BITCAST, SELECT, and SELECT_CC opcode, we need to do down and check their operands as if f128 is TypeLegal. So there is no simpler way to treat it the same as other SoftFloatRes_* functions.
For Register, CopyFromReg, CopyToReg, ConstantFP, FABS, FCOPYSIGN, and FNEG they are simple enough to skip ScanOperands, so we can let them return the same SDNode and pretend that the result node was changed and goto NodeDone. So I simplified all of them into the old switch cases without new extra functions.


================
Comment at: lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp:154
@@ -111,1 +153,3 @@
     SetSoftenedFloat(SDValue(N, ResNo), R);
+    // Some soften sub-methods, e.g. those calling TLI.makeLibCall,
+    // do not call ReplaceValueWith and depend on the ScanOperands
----------------
See updated comment. Examples are those calling TLI.makeLibCall.


================
Comment at: lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp:168
@@ -113,3 +167,3 @@
 
 SDValue DAGTypeLegalizer::SoftenFloatRes_BITCAST(SDNode *N) {
   return BitConvertToInteger(N->getOperand(0));
----------------
Okay, changed to an assert, suppress compiler warning, and simple return.



http://reviews.llvm.org/D11438





More information about the llvm-commits mailing list