[PATCH] D15134: Part 1 to fix x86_64 fp128 calling convention.
Chih-Hung Hsieh via llvm-commits
llvm-commits at lists.llvm.org
Fri Jan 8 15:23:35 PST 2016
chh added inline comments.
================
Comment at: llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:8728-8740
@@ -8725,1 +8727,15 @@
+ // copysign(x, fp_round(y)) -> copysign(x, y)
+ // Do not optimize out type conversion of f128 type yet.
+ // For some target like x86_64, configuration is changed
+ // to keep one f128 value in one SSE register, but
+ // instruction selection cannot handle FCOPYSIGN on
+ // SSE registers yet.
+ SDValue N1 = N->getOperand(1);
+ EVT N1VT = N1->getValueType(0);
+ EVT N1Op0VT = N1->getOperand(0)->getValueType(0);
+ return (N1.getOpcode() == ISD::FP_EXTEND ||
+ N1.getOpcode() == ISD::FP_ROUND) &&
+ (N1VT == N1Op0VT || N1Op0VT != MVT::f128);
+}
+
SDValue DAGCombiner::visitFCOPYSIGN(SDNode *N) {
----------------
spatel wrote:
> Why is an x86-specific limitation being handled in DAGCombiner? Maybe no target supports f128, so it doesn't matter, but this seems wrong.
>
I thought this optimization won't work for f128 given that current
llvm targets I know do not keep f128 in one register and have not defined
required instruction selection patterns. Instead of keeping this
optimization here for all targets and disable it in a target specific
way, it seems simpler to disable it here for f128 and enable such optimization
for any target later.
That being said, I didn't check all ad-hoc llvm floating point optimizations.
If my assumption is wrong or if there is a simpler way to handle this,
please feel free to suggest any different implementation.
Thanks.
Repository:
rL LLVM
http://reviews.llvm.org/D15134
More information about the llvm-commits
mailing list