[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 mean sure, but I still don't quite get the limitation of "an attribute on the ModuleOp": an attribute is in the MLIRContext already and you get access to it from the IR.

Right, but how do you _populate_ the IR with those attributes/numbers?

A front-end can read some Json file or take an LLVM TTI and populate these attributes, but now we're duplicating the same logic for every new front-end. A vanilla IR could be annotated with those attributes by a pass, but then MLIR needs to know where to get them from, which goes back to the original point: they'll come from LLVM's TTI, some Json file, some command line options, and we need a single place to categorize them, interpret them, select default values when none are provided, handle errors, etc.

Even if the attributes are in IR, we still need to know what to do with them. How to use them as cost modelling, how to interpret different target attributes, and what do these things mean. There has to be a piece of infrastructure that handles all of this in MLIR regardless of where it lives or where it comes from. That infrastructure is what this PR is trying to build.

On the matter of having IR being the input file (rather than Json), it's not as simple as it may look.

In time, I want to:
* be able to try different schedules/costs for the same IR (ex. ML-GO style).
* lower the same IR for different targets (ex. linalg-on-tensor for CPU/GPU/NPU) which will use different parts of the same multi-target schedule/costs.
* overlap command line options over configuration file parameters and that over LLVM's TTI information on the same cost model/target description infrastructure (so I only pass one option and take the rest from the default target).
* have separate cost models (high-level for tiling, low-level for vectorization) from the same target descriptor at separate times in the compilation lifetime.
* allow downstream targets to add specific costs/properties/questions that will only be used by the downstream code, which can be numbers or formulas or values.
* do all of the above at compile time, for multi-versioning, possibly replacing the target from LLVM, Json, options, before outputting the first binary out.

Most of the above gets clumsy if I have to edit the IR, remove some attributes (and not others), add some attributes (and have merge semantics), etc. And in the end, how many attributes will we have for any small piece of IR for any particular target? If LLVM's TTI is any indication, probably hundreds, per target.

Finally, we're not proposing anything different than what we have in LLVM. It's a target descriptor that lives in the compiler and gets used by passes to ask questions about code generation. If this whole tangent is about being in `MLIRContext`, then by all means, let's move it somewhere else.

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