[PATCH] D106028: [AArch64][SelectionDAG] Add legalization for widening LOAD/MLOAD.

Eli Friedman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jul 19 13:34:58 PDT 2021


efriedma added inline comments.


================
Comment at: llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp:4048
+
+  // FIXME: Figure out how to replace constant "2".
+  if (VT.isScalableVector() && VT.getVectorMinNumElements() % 2 != 0) {
----------------
sdesmalen wrote:
> Do we also want to do this for other element-counts that are not a power of 2? (e.g. `<vscale x 6 x i8>`)
> 
> Was this code intended to work for `<vscale x 1 x eltty>` ? (I tried that a few days ago with this patch and ran into some failures. I didn't really investigate further though)
Should work for 1, I guess?  Not sure I actually tried it.  But note we only support a very limited set of operations.  See also D105591.

For `<vscale x 6 x i8>`, we can use a different sequence: generate extloads for `<vscale x 2 x i64>` and `<vscale x 4 x i32>`, and merge them together.  GenWidenVectorLoads should handle that in theory; not sure how well it works in practice.

I'll add more testcases, in any case.


================
Comment at: llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp:4135
+  MachineMemOperand *MemOp = MF.getMachineMemOperand(
+      N->getMemOperand(), 0, MemoryLocation::UnknownSize);
+
----------------
sdesmalen wrote:
> Should `MemoryLocation::UnknownSize` only be used for the scalable case?
There's a general restriction on memoperands in selectiondag: the size of the operand must be at least the size of the memory VT.  I didn't really want to think about precisely what MemoryLocation we could be using instead...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106028



More information about the llvm-commits mailing list