[Mlir-commits] [mlir] [uArch][XeGPU] Add XeGPU uArch definition. (PR #153706)

[Md Abdullah Shahneous Bari]

mshahneo wrote:

> High-level comment: could the "family of ops" be represented by `OpInterface`s? That is, are the XeVM ops (and those of XeGPU) in each of the families such that they correspond to each of the `Instruction` structs that you have? If so, might be nicer to attach the required shape information directly to the ops (though presumably through static methods (on interfaces) so you don't first need an instance of an op to learn about its required shapes).

Hi Rolf,

Thank you for bringing it up. I don't have any opposition to this in principle. However, I have a few concerns/discussion points,

- The instructions (and their restrictions) have a scope (work-item, subgroup, workgroup). However, XeGPU ops operate in all 3 of those scopes, how the interfaces would look like for a XeGPU op that is not the native scope of that instruction. For example, DPAS instruction is natively subgroup scoped. Now, An XeGPU op with workgroup scope, how would specific interfaces (e.g., getSupportedShapes) would work? Do they return null, or something else.
- The second concern is, now that both XeGPU and XeVM ops would have to implement the interfaces, that may add extra code. One way to resolve it would be to have the common implementation of these interfaces someplace. In that vein, I would argue that the current setup could be that. In the next PRs, we could make XeGPU/XeVM ops implement these interfaces, but internally call, the instruction implemented version. (@chencha3, @silee2 what it is you opinion as XeGPU and XeVM code owner?)


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