[llvm] LAA: scale strides using type-size (NFC) (PR #124529)

[David Sherwood via llvm-commits]

================
@@ -1990,25 +1986,32 @@ MemoryDepChecker::getDependenceDistanceStrideAndSize(
     return MemoryDepChecker::Dependence::Unknown;
   }
 
-  uint64_t TypeByteSize = DL.getTypeAllocSize(ATy);
-  bool HasSameSize =
-      DL.getTypeStoreSizeInBits(ATy) == DL.getTypeStoreSizeInBits(BTy);
-  if (!HasSameSize)
-    TypeByteSize = 0;
+  TypeSize AStoreSz = DL.getTypeStoreSize(ATy),
+           BStoreSz = DL.getTypeStoreSize(BTy);
+
+  // Fail early if either store size is scalable.
+  if (AStoreSz.isScalable() || BStoreSz.isScalable())
----------------
david-arm wrote:

This is definitely not NFC. Previously if *both* AStoreSz and BStoreSz were scalable and have the same known minimum size then they would be treated as equal, see the code you've removed:

```
  bool HasSameSize =
      DL.getTypeStoreSizeInBits(ATy) == DL.getTypeStoreSizeInBits(BTy);
  if (!HasSameSize)
    TypeByteSize = 0;
```

It looks like what you're effectively doing is trying to ignore scalable sizes to make life easier for storing out the scaled stride. I think you have a couple of options:

1. Change the MaxStride, CommonStride and TypeByteSize variables to use TypeSize now instead and remove this code:

```
  if (AStoreSz.isScalable() || BStoreSz.isScalable())
    return MemoryDepChecker::Dependence::Unknown;
```

Perhaps you could change MaxStride, CommonStride and TypeByteSize to using TypeSize in a separate NFC patch? Or, ...

2. Create a separate stand-alone patch that explicitly bails out for scalable vectors, then rebase this patch on top of that. It does look like there was previously a bug with this code `uint64_t TypeByteSize = DL.getTypeAllocSize(ATy);` since it was clearly assuming a fixed-size type.

I'm happy with either approach, although I suspect option 2 is less effort. :)

https://github.com/llvm/llvm-project/pull/124529