[Mlir-commits] [mlir] Reimplementing target description concept using DLTI attribute (PR #92138)

Renato Golin llvmlistbot at llvm.org
Mon Jun 17 11:27:32 PDT 2024


================
@@ -194,6 +194,116 @@ def DataLayoutSpecInterface : AttrInterface<"DataLayoutSpecInterface"> {
   }];
 }
 
+def TargetDeviceSpecInterface : AttrInterface<"TargetDeviceSpecInterface"> {
+  let cppNamespace = "::mlir";
+
+  let description = [{
+    Attribute interface describing a target device description specification.
+
+    A target device description specification is a list of device properties (key)
+    and their values for a specific device. The device is identified using "device_id"
+    (as a key and ui32 value) and "device_type" key which must have a string value.
+    Both "device_id" and "device_type" are mandatory keys. As an example, L1 cache
+    size could be a device property, and its value would be a device specific size.
+
+    A target device description specification is attached to a module as a module level
+    attribute.
+  }];
+
+  let methods = [
+    InterfaceMethod<
+      /*description=*/"Returns the list of layout entries.",
+      /*retTy=*/"::mlir::DataLayoutEntryListRef",
+      /*methodName=*/"getEntries",
+      /*args=*/(ins)
+    >,
+    InterfaceMethod<
+      /*description=*/"Returns the entry related to the given identifier, if "
+                      "present.",
+      /*retTy=*/"::mlir::DataLayoutEntryInterface",
+      /*methodName=*/"getSpecForIdentifier",
+      /*args=*/(ins "::mlir::StringAttr":$identifier),
+      /*methodBody=*/"",
+      /*defaultImplementation=*/[{
+        return ::mlir::detail::filterEntryForIdentifier($_attr.getEntries(),
+                                                        identifier);
+      }]
+    >,
+    InterfaceMethod<
+      /*description=*/"Checks that the entry is well-formed, reports errors "
+                      "at the provided location.",
+      /*retTy=*/"::mlir::LogicalResult",
+      /*methodName=*/"verifyEntry",
+      /*args=*/(ins "::mlir::Location":$loc),
+      /*methodBody=*/"",
+      /*defaultImplementation=*/[{ return ::mlir::success(); }]
+    >,
+    InterfaceMethod<
+      /*description=*/"Returns max vector op width identifier. ",
+      /*retTy=*/"::mlir::StringAttr",
+      /*methodName=*/"getMaxVectorOpWidthIdentifier",
+      /*args=*/(ins),
+      /*methodBody=*/""
+    >,
+    InterfaceMethod<
+      /*description=*/"Returns L1 cache size identifier identifier. ",
+      /*retTy=*/"::mlir::StringAttr",
+      /*methodName=*/"getL1CacheSizeInBytesIdentifier",
+      /*args=*/(ins),
+      /*methodBody=*/""
+    >,
+  ];
----------------
rengolin wrote:

I'm not sure how the max vector size helps, with not all ops being supported in all vector sizes, etc.

For the L1, the problem is that we don't have any other target feature to show it works in a test.

How about, in the spirit of data layout, we have a string of cache levels instead? A shared format that describes L1/2/3 in CPUs as well as Thread/Warp/Core memory access for GPUs?

That'd be a generic format that we can encode in a string and work across various targets, and not be a specific property of CPUs.

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


More information about the Mlir-commits mailing list