[PATCH] [x86] Add a ZERO_EXTEND_VECTOR_INREG DAG node and use it when widening vector types to be legal and a ZERO_EXTEND node is encountered.
chandlerc at gmail.com
Wed Jul 9 03:37:36 PDT 2014
Comment at: lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp:750
@@ +749,3 @@
+ return DAG.getNode(ISD::BITCAST, DL, VT,
+ DAG.getVectorShuffle(SrcVT, DL, Zero, Src, ShuffleMask));
Chandler Carruth wrote:
> Matt Arsenault wrote:
> > Benjamin Kramer wrote:
> > > Can we get away with creating illegal shuffles here or should we ask the backend if the mask is legal first?
> > I'm pretty sure this needs to be checked. I fixed a similar issue in http://reviews.llvm.org/D4320
> I believe we can get away with this, but it's a bit dicey I agree.
> First, to Matt's point -- we can *definitely* create illegal types here, i don't know whot D4320 is talking about. If you look at SelectionDAGISel::CodeGenAndEmitDAG, you'll see that we re-type-legalize after the vector operation legalization. There are also specific comments around the vector operation legalization that it is expected to at times produce illegal types.
> What we can't do here is produce an illegal *vector* type which could then result in an illegal vector operation, which could then result in scalarization with an illegal scalar type. We won't get a chance to fix the scalarized version unless we produce it in this pass of the legalizer.
> So the risk in the current approach is that I don't know if the legalizer correctly recurses on the newly created VECTOR_SHUFFLE node to legalize that operation. If it doesn't then we would need to recurse on it within VectorLegalizer. I'll check that.
Just to close the loop, in LegalizeVectorOps.cpp:307-311 the code recurses over any legalized result node which differs from the original node, so returning an illegal VECTOR_SHUFFLE node (or even a bitcast of a VECTOR_SHUFFLE node, as LegalizeOp always recurses across operands) should always re-enter the vector operation legalization framework before we finish the phase of legalization. So essentially, this does appear to be a valid way of recursively delegating legalization from one node to another provided we don't end up with a cycle. If we do, it will show up as an infinite loop immediately, so I'm not too worried.
More information about the llvm-commits