banach-space wrote:
Thanks - great to finally be reaching this stage! I have a few high-level
questions and suggestions:
**1. Why is the scalable dimension always [4]?**
From the current tests, it looks like the scalable dim is always `[4]`. Could
you remind me why that value is chosen?
**2. Reduce duplication in the 4x8x4 tests**
The current tests differ only in terms of **input**/**output** and `extsi` vs
`extui`. It should be possible to reduce duplication by extracting shared logic
into helpers, and writing 4 separate entry points (set via `entry_point`) to
isolate the differences.
For example:
```mlir
func.func @main_smmla() {
// Init LHS, RHS, ACC
// CHECK-LINES for LHS
print(lhs);
// CHECK-LINES for RHS
print(rhs);
arith.extsi (lhs)
arith.extsi (rhs)
vector.contract
// CHECK-LINES for ACC
print(acc);
}
```
This would keep the test logic focused and easier to maintain.
**3. Add checks for generated IR (LLVM dialect)**
It would be good to verify that the lowered IR includes the correct SME MMLA
intrinsics. For example:
```mlir
// CHECK-COUNT-4: llvm.intr.smmla
```
This would help confirm both correctness and that the expected number of
operations are emitted.
**4. Consider toggling VL within tests**
Have you considered toggling the scalable vector length (`VL`) within the test?
That would allow verifying behaviour for multiple `VL` values.
From what I can tell, this would only work if the inputs are generated inside a
loop, similar to this example:
https://github.com/llvm/llvm-project/blob/88f61f2c5c0ad9dad9c8df2fb86352629e7572c1/mlir/test/Integration/Dialect/Vector/CPU/ArmSME/load-vertical.mlir#L19-L37
That might be a nice validation of the "scalability" aspect.
https://github.com/llvm/llvm-project/pull/140573
_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
