[Mlir-commits] [mlir] [MLIR][DLTI] Introduce DLTIQueryInterface and impl for DLTI attrs (PR #104595)

[Rolf Morel]

================
@@ -93,20 +85,63 @@ def DLTI_DataLayoutSpecAttr :
 
     /// Returns the stack alignment identifier.
     StringAttr getStackAlignmentIdentifier(MLIRContext *context) const;
+
+    /// Returns the attribute associated with the key.
+    FailureOr<Attribute> query(DataLayoutEntryKey key) {
+      return llvm::cast<mlir::DataLayoutSpecInterface>(*this).queryHelper(key);
+    }
+  }];
+}
+
+def DLTI_MapAttr : DLTIAttr<"Map", [DLTIQueryInterface]> {
+  let summary = "A mapping of DLTI-information by way of key-value pairs";
+  let description = [{
+    A Data Layout and Target Information map is a list of entries effectively
+    encoding a dictionary, mapping DLTI-related keys to DLTI-related values.
+
+    This attribute's main purpose is to facilate querying IR for arbitrary
+    DLTI-related key-value associations. Note that facility functions exist to
+    perform recursive lookups on nested DLTI map attributes.
+
+    Consider the following shallow usage of a DLTI-map
+    ```
+    #dlti.map<#dlti.dl_entry<"CPU::cache::L1::size_in_bytes", 65536 : i32>>
+    ```
+    versus nested maps, which make it possible to obtain sub-dictionaries of
+    related information (with the following example making use of other
+    attributes that also implement the `DLTIQueryInterface`):
+    ```
+    #dlti.target_system_spec<"CPU":
----------------
rolfmorel wrote:

These two dictionaries are not meant to be equivalent, i.e. will not respond the same upon being queried.

The first holds one string key and one value, where the key's string happens to look structured. From my side, there is no intention to specially interpret the `::` inside such keys: such a string is just a plain key, in this case of a flat dictionary. The only successful query for it is: `transform.dlti.query ["CPU::cache::L1::size_in_bytes"] at ...`

The second example is there to demonstrate explicitly representing the structured relation among the data.  `transform.dlti.query ["CPU::cache::L1::size_in_bytes"] at ...` will fail on it. Instead `transform.dlti.query ["CPU","cache","L1","size_in_bytes"] at ...` is to be used. `transform.dlti.query ["CPU","cache","L1d","size_in_bytes"] at ...` gives the other leaf value contained by in the nested map.

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