During the ODM on the topic (Open MLIR Meeting 5/24/2023: RFC Discussion about "Distinct Attribute" in MLIR) two paths forward have been discussed:
- A resource based solution,
- An attribute based solution that uses the alias printing facilities to implement distinct attributes.
I did some initial experimentation with resources. It seems the current implementation also suffers from non-determinism problem that my initial mutable attribute based solution had. Essentially, the resource is assigned a unique name during resource creation rather than during printing (llvm-project/DialectResourceBlobManager.cpp at 60b7dbb670afceab7d897699e00073b50e4c384a · llvm/llvm-project · GitHub). If the resources are created in parallel - for example in a function pass - the naming may be non-deterministic due to the threading.
The behavior can be tested using the following code snippet:
OpBuilder builder(context);
ArrayRef<int32_t> data(0);
auto type = RankedTensorType::get(0, builder.getI32Type());
SmallVector<Attribute> attributes(20);
parallelFor(context, 0, 20, [&](size_t i) {
attributes[i] = DenseI32ResourceElementsAttr::get(
type, "distinct", UnmanagedAsmResourceBlob::allocateInferAlign(data));
});
for (const auto &it : llvm::enumerate(attributes)) {
module.get()->setAttr("llvm.access_group_" + std::to_string(it.index()),
it.value());
}
It creates resources in parallel and adds them to the module. On a multi-threaded system the resulting attribute assignment is non-deterministic / run dependent.
As the attribute alias printing already implements the logic to number attributes during printing,
the attribute based solution seems preferable over implementing a similar mechanism for resources? Or did I miss some mechanism that can produce unique resource names in a deterministic manner?