[PATCH] D79587: [CodeGen][SVE] Legalisation of extends with scalable types

[Eli Friedman via Phabricator via cfe-commits]

efriedma added inline comments.


================
Comment at: llvm/lib/Target/AArch64/AArch64ISelLowering.cpp:10676
+    ConstantSDNode *C = dyn_cast<ConstantSDNode>(Dup->getOperand(0));
+    uint64_t ExtVal = C->getZExtValue();
+
----------------
kmclaughlin wrote:
> efriedma wrote:
> > Do you need to truncate ExtVal somewhere, so you don't end up with a DUP with an over-wide constant?
> I've changed the call to `getNode` below that creates the DUP to use `DAG.getAnyExtOrTrunc` (similar to what we do in LowerSPLAT_VECTOR)
I'm specifically concerned that you could end up with something like `(nxv16i8 (dup (i32 0x12345678)))`.


================
Comment at: llvm/lib/Target/AArch64/AArch64ISelLowering.cpp:13300
+    // is another unpack:
+    // 4i32 sign_extend_inreg (4i32 uunpklo(8i16 uunpklo (16i8 opnd)), from 4i8)
+    // ->
----------------
kmclaughlin wrote:
> efriedma wrote:
> > It seems a little fragile to assume the inner VT of the SIGN_EXTEND_INREG is exactly the type you're expecting here.  Probably worth at least adding an assertion to encode the assumptions you're making.
> I've added an assert above here to make sure the sign_extend_inreg and unpack types match, is this the assumption you were referring to?
We assert that SIGN_EXTEND_INREG has valid operand/result types elsewhere.

I was more concerned about the inner VT (`cast<VTSDNode>(N->getOperand(1))->getVT();`).  You could end up creating an invalid SIGN_EXTEND_INREG if the type is something weird, like a non-byte-size integer type.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79587/new/

https://reviews.llvm.org/D79587