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

[Charitha Saumya]

================
@@ -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");
----------------
charithaintc 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 probe for the map attributes using `getAttrOfType<xegpu::SGMapAttr>` for any op.
Yes this is the plan for distribution pass.
> 
> 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.
For XeGPU ops we can still introduce an optional attribute with appropriate naming. For all other ops, yes I agree. We need some kind of naming convention to tackle this issue. 
> 
> Anyway, I was more curious about some documentation for this. `SGMapAttr` docs don't capture this kind of usage.
I am making a note to fix this. 



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