[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:

Just to expand on the target lookup strategy, this is one alternative we discussed internally. Ignore the `getContext()` for now, let's just assume this is whatever gets you the target descriptor handler.

The first (naive and wrong) behaviour could be:
* If the op has a target attribute:
  * `target = op.getContext().getTarget(op.getTargetID()); // This could be an ID or a string into a map`
* Else
  * `target = op.getContext().getDefaultTarget(); // Default target is target 0`

A more advanced lookup would need to recurse:
* Else
  * Iterate through parents until target ID is found (module should be target 0)
  * `target = op.getContext().getTarget(op.getTargetID());`

This would be costly, as no op today has a target ID and we assume less of them will have it than not have it.

Two alternatives are:
1. Mandate every op to have a target ID. This breaks compatibility, increases parsing and analysis costs, touches every op, including downstream ones. Not viable.
2. Make so that only a few ops will ever have such attribute, a bit like a symbol table. This could be modules, functions and certain grouping operations (like Frank's / Ivan's). This is backwards compatible and you only pay the cost if you want a target descriptor in the first place.

The latter above is more complex than just taking the local op target, but it's a manageable complexity, unlike the other options. For example, a pass that uses target information and cost models would look for such operations and dispatch a transform / rewrite onto that region and nowhere else, passing the target descriptor with it, guaranteeing no recursive search will need to happen.

But any of these better solutions are into the future. Right now, we're worried about the basic infrastructure, for example:
* Where does it live? If not context, where would be a more appropriate global context that only spans the module?
* How do we query it? If not via device ID, do we just attach references to the actual target/model directly to the ops (regions, functions, modules)?

Also remember, the compiler isn't meant to use the target descriptor directly. This is an interim stage while we get the cost model up, and then passes/transforms will use the cost model to ask questions, which in turn will enquire the target descriptor for information.

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