[Mlir-commits] [mlir] [MLIR][XeGPU] Introduce `xegpu::uArch` usage in target-sensitive passes (PR #163801)

[Jianhui Li]

================
@@ -557,23 +599,54 @@ void LayoutInfoPropagation::visitDpasOp(
     ArrayRef<const LayoutInfoLattice *> results) {
   VectorType aTy = dpas.getLhsType();
   VectorType bTy = dpas.getRhsType();
-  propagateIfChanged(
-      operands[0], operands[0]->meet(getSIMTLayoutInfoForDPASOperand(aTy, 0)));
-  propagateIfChanged(
-      operands[1], operands[1]->meet(getSIMTLayoutInfoForDPASOperand(bTy, 1)));
+
+  auto uArch = getUArch(getChipStr(dpas).value_or(""));
+  const int subgroupSize = uArch->getSubgroupSize();
+  auto uArchInstruction =
+      std::static_pointer_cast<xegpu::uArch::DPASInstruction>(
+          uArch->getInstruction(xegpu::uArch::InstructionKind::DPAS));
+  const int maxALen =
+      uArchInstruction->getSupportedM(aTy.getElementType()).back();
+  const int maxBLen =
+      uArchInstruction->getSupportedK(bTy.getElementType()).back();
+  SmallVector<int> instDataA = {maxALen, subgroupSize};
----------------
Jianhui-Li wrote:

I don't see a need to support 8+4.  For user's input 12, we can't give 8 the max inst_data value as the current logic does. instead, we should give 4.  
>>do we only work with multiples of the max size in the foreseeable future
I don't see it worth to support complex scheme like 8+4. We can stick to the max of supported sizes among all divisors of user provided shape. 


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