[Mlir-commits] [mlir] [mlir] Target Description and Cost Model in MLIR (PR #85141)

[Renato Golin]

================
@@ -240,6 +241,9 @@ class MLIRContext {
   /// (attributes, operations, types, etc.).
   llvm::hash_code getRegistryHash();
 
+  /// Get context-specific system description
+  SystemDesc &getSystemDesc();
----------------
rengolin wrote:

I think we're talking about different things. But I have mixed them up a bit on my answer above, so I understand the confusion.

One thing is op attribute to indicate target features that are specific to the op, generally low level ops like in the GPU dialect. Here, there's a pass that lowers IR into those ops with a particular semantics, encoded in the attributes.

Another is how do we get to those decisions in the first place. We may very well end up with a lot of target attributes encoded in IR, at high and low level, but there still needs to be a framework that will help find _which of them_ to create, or even how to tile and fuse more than one op, etc. This cannot be an attribute to a particular op.

In my answer I should have kept to the latter: where do we take those properties from (TTI, Json, cmd-line args); But I have also pushed a little bit on how to represent them (function/op attributes, regions). This PR is about the TTI infrastructure, not the IR representation.

Why did I mix them? Because of the `MLIRContext` question. As @nhasabni said, regardless of where we keep the TTI/Cost model, we will need access to it from passes, transforms, lowering, perhaps even the front-end will need to use it, in order to generate the correct IR ops or perform the most accurate analysis. 

Moreover, device transformations may need to know about the host properties to make efficient decisions, so we should have a way to ask about _any_ target from _any_ place in the code that handles IR. The `MLIRContext` is one of those places, but not the only one. It could even be a global structure.

We have discussed two designs:
1. A single target descriptor framework for all targets, indexed by some ID (numeric, text, hash) which is accessible from any op (like `op.getContext().getTTI()`).
2. A initial target descriptor framework for all targets that creates IR passing individual TTIs (as a pointer to a singleton) to each sub-graph (module? function? op?).

The first one seems simpler to implement and more generic to use. Since it's not clear what the actual core usage will be, we picked this one. Also, if you squint hard enough, you can see that (2) is basically the same as (1) in complexity, just a different API and harder to access _other targets'_ info.

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