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

Matt Arsenault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jan 11 07:58:40 PST 2018


arsenm added inline comments.


================
Comment at: lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp:175
+      && Op.getValueType().getVectorNumElements() == 1)
+    Op = GetScalarizedVector(Op);
   EVT NewVT = N->getValueType(0).getVectorElementType();
----------------
samparker wrote:
> arsenm wrote:
> > samparker wrote:
> > > arsenm wrote:
> > > > Can you add an assert that the v1 type isn't legal?
> > > Hi,
> > > The added assert is causing issues in our AArch64 tests... why is it necessary?
> > It probably isn't necessary, but unlike the other operations handled here, it would make sense for bitcast to not separately scalarize its operand if v1 is a legal type. However, v1 as legal is a degenerate case which probably should not be allowed. It looks like AArch64 is using this as a hack for some reason with a FIXME about it.
> Could you point me to this FIXME please? I'm still confused as to why we should prevent a scalar from being produced just because the vector is legal, is this because of how the legalizer is expected to operate?
AArch64ISelLowering.cpp:596
  if (Subtarget->hasNEON()) {
    // FIXME: v1f64 shouldn't be legal if we can avoid it, because it leads to
    // silliness like this:

Bitcast is possibly special because it is a conversion. If the legalizer is expecting to leave some v1 operations in it, then it would probably be required to leave the bitcast in case some operation was expecting to legalize in terms of a bitcast from an 1 vector.


Repository:
  rL LLVM

https://reviews.llvm.org/D41126





More information about the llvm-commits mailing list