[Mlir-commits] [mlir] [mlir][xegpu] Improve XeGPU op verification logic for SIMT flavor and update tests. (PR #127920)

[Adam Siemieniuk]

================
@@ -610,20 +620,61 @@ void UpdateOffsetOp::build(OpBuilder &builder, OperationState &state,
 LogicalResult DpasOp::verify() {
   int64_t lhsRank = getLhsType().getRank();
   int64_t rhsRank = getRhsType().getRank();
-
-  if (lhsRank != 2 || (rhsRank != 2 && rhsRank != 3))
-    return emitOpError("expecting lhs to be a 2D vector, and rhs to be either "
-                       "2D or 3D (packed) vector.");
-
+  int64_t resultRank = getResultType().getRank();
   auto lhsShape = getLhsType().getShape();
   auto rhsShape = getRhsType().getShape();
-  auto bK = rhsRank == 3 ? rhsShape[0] * rhsShape[2] : rhsShape[0];
-  if (bK != lhsShape[1])
+  auto resultShape = getResultType().getShape();
+
+  auto sgMapA = (*this)->getAttrOfType<xegpu::SGMapAttr>("sg_map_a");
----------------
adam-smnk wrote:

Hmm that's a valid concern, I haven't considered other dialects in that but we'll have a mix of vector and arith too.
Thankfully, a distribution pass can still generically access probe for the map attributes using `getAttrOfType<xegpu::SGMapAttr>` for any op.

Perhaps, we'll have to approach it differently and have consistent naming convention across all ops e.g., enumerated by operand position `sg_map_0`, `sg_map_1` etc. At this point, the `sg_map` attribute probably should be tied to operations in general instead of `TensorDesc`. Well, just food for thought.

Anyway, I was more curious about some documentation for this. `SGMapAttr` docs don't capture this kind of usage.

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