[PATCH] D130692: [AArch64][SVE] Expand gather index to 32 bits instead of 64 bits

Paul Walker via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 31 10:00:31 PDT 2022


paulwalker-arm added inline comments.


================
Comment at: llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:296
                              bool Signed) {
-  if (N->getOpcode() != ISD::BUILD_VECTOR)
-    return false;
----------------
I'm probably just being paranoid but with this code now sitting after the call to `getScalarSizeInBits()` can you add something like `assert(N->getValueType(0).isVector() && "Expected a vector!");` here? just in case. 


================
Comment at: llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:301
+  if (N->getOpcode() == ISD::ZERO_EXTEND)
+    return !Signed;
+  if (N->getOpcode() == ISD::SIGN_EXTEND)
----------------
It's not sufficient to only consider the result type of the extend.  For example, take
```
isVectorShrinkable(zext_to_i64(i48_node, 32, false)
```
With the current implementation you'll return true but:
```
zext_to_i64(trunc_to_i32(i48_node)) != zext_to_i64(i48_node)
```
For the sext & zext cases I think you also need N's operand to be `<= NewEltSize`


================
Comment at: llvm/test/CodeGen/AArch64/sve-fixed-length-masked-gather.ll:1036-1041
+; CHECK-NEXT:    ptrue p1.s, vl32
 ; CHECK-NEXT:    ld1d { z0.d }, p0/z, [x0]
-; CHECK-NEXT:    ld1sw { z1.d }, p0/z, [x1]
+; CHECK-NEXT:    ld1w { z1.s }, p1/z, [x1]
 ; CHECK-NEXT:    fcmeq p1.d, p0/z, z0.d, #0.0
-; CHECK-NEXT:    ld1d { z0.d }, p1/z, [x2, z1.d, lsl #3]
+; CHECK-NEXT:    sunpklo z0.d, z1.s
+; CHECK-NEXT:    ld1d { z0.d }, p1/z, [x2, z0.d, lsl #3]
----------------
I've had a look and believe the issue is that for fixed length vectors we don't want to shrink `Index` when the main datatype of the gather/scatter is a vector of 64bit values because the data elements must line up with the offset elements and when that is not the case operation legalisation will "fix" it by explicitly extending which ever is the smaller type.

This is fixable within `findMoreOptimalIndexType` by just bailing about of such types just before the `// Can indices be trivially shrunk?` block.

The reason this is a fixed-length only problem is because for scalable vectors we use an "unpacked" format where each element of a `nxv2i32` vector sits within the bottom half of each element of a `nxv2i64` vector so element of differing sizes remain aligned to each other.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130692



More information about the llvm-commits mailing list