[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 wouldn't suggest serializing all of TTI as attribute, the attribute is just a "target id" that implement the right interface. It's orthogonal to how the interface is implemented.

That was one of the original points, we're good with that.

But we still have the same problems:
* where does that target id live - op/func/region/module - and how does that affect passes?
* who populates the target id as attributes? How long do they live? where does the actual map lives?
* do we want the maps to be a global? context? passed through as args?
* etc.

A "target id" is just a name into a map that does not have to be known by the compiler. It can be a known target (TTI), or an unknown target (a key in a config file). It could even change throughout the compiler (moving compute across devices, changing between cost models of the same device).

These questions are more important, in my view, than what kind of attribute we add.

> We probably need a better design doc, likely with a running example, this PR as it is does not tell enough of the story for me to see where this is going.

This problem is so large that it's virtually impossible to have a PR with a running example that covers all cases. We're trying to get a head start on one case: a config file property into some compiler passes questions.

This is unlikely the final design or even the most popular usage, but it's one that we can start to get our feet wet.

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