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

Renato Golin llvmlistbot at llvm.org
Fri Mar 15 05:20:49 PDT 2024


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

We discussed this internally and there isn't a clear answer. We do agree that we need an IR annotation, that's why the target descriptor has a `targetID`. In theory, the context is only being used as a singleton for the whole module, and the way you query the target is to get the operation's target attribute (or its parents) and query the context for a target of that ID. This is not the most robust design, but we're still grasping at straws on how this will all fit together, so it sounded like a reasonable starting point.

There is usually a single host there could be multiple targets (including the host), but the host can be a different target than the one you're compiling on. For example, compile in the head node (older machine) to run on a cluster node (newer machine with multiple devices). So we need to provide at least one host and one target. Of course, the default value for those is the same: the current machine. Passing "names" would trigger an LLVM target lookup, passing config files would trigger parsing of such files. We could treat host/target as just target(s), not sure we need a difference here.

In the IR, we may use different target descriptors for different functions, or perhaps even different ops (say, a single `linalg.generic`), but that granularity can be too costly. So we're discussing if we leave the target information as a function attribute (and outline target code) or if we create regions that define targets, like the ones proposed by another team we collaborate with (@fschlimb, @Hardcode84).

To avoid this discussion, we just have here the possibility of having multiple devices, but not yet making full use of it. We're trying to get the basic functionality first before we start discussing the merits of target annotations and where they live (and how they're recursively searched if not found, and the compile time cost of it).

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


More information about the Mlir-commits mailing list