[PATCH] D41126: [SelectionDAG] Fixed f16-from-vector promotion problem

Tim Renouf via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Dec 19 09:34:42 PST 2017


tpr added inline comments.


================
Comment at: lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp:172-178
+  SDValue Op = N->getOperand(0);
+  if (Op.getValueType().isVector()
+      && Op.getValueType().getVectorNumElements() == 1)
+    Op = GetScalarizedVector(Op);
   EVT NewVT = N->getValueType(0).getVectorElementType();
   return DAG.getNode(ISD::BITCAST, SDLoc(N),
+                     NewVT, Op);
----------------
arsenm wrote:
> There is already ScalarizeVecOp_BITCAST, so it seems the intent was this is a separate step. My question is more of why isn't that happening already in this example
Looking at how a single node is handled in DAGTypeLegalizer::run:

First it looks at the result type. If it needs legalizing, it calls the applicable function (ScalarizeVectorResult in our case), and then skips past the code that checks the operand types. It is assuming that the ScalarizeVecRes_* also scalarized the operand(s) where applicable. That seems to be true for everything except bitcast, presumably because the operand type is less predictable.

So that is why it is not calling ScalarizeVecOp_BITCAST.

Can you think of a better way of fixing this? Maybe special case bitcast so, after creating the new one in ScalarizeVecRes_BITCAST, it somehow gets added back to the worklist so its operand gets scanned? Or shall we stick with the fix I have?


https://reviews.llvm.org/D41126





More information about the llvm-commits mailing list