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

[Fabian Mora]

fabianmcg wrote:

Thanks for your responses @nhasabni !

> This PR does not discuss the representation of devices. It is meant to get the boiler plate infra support that we envision will be enhanced further.

My question is not about the current PR, but instead about how would one represent those systems with the boiler plate infra. Because from what I understood, right now it's a flat representation, so it works well for a single heterogeneous node, but more complex systems are not straightforward, and we should get that right from the start.


>  It is mandatory currently because the passes (or other users) can identify a particular device using a device ID in order to query its properties.

My comment is about the case: `system1 = [deviceX[id = 0], deviceX[id = 1]]`,  `system2 = [deviceX[id = 1], deviceX[id = 0]]`. In many cases `system1 == system2`, however, they are not the same by forcing ids. Moreover, it's also fragile, because a pass that works on `system1` might not work on `system2` because of the ordering.

Also, why do you need the ID to be stored in the device to query the properties? As far as I could tell, devices are placed in an array, so `attr.getEntries()[devId]` should work.


> Yes, we would certainly need similar APIs for L2, L3, etc.
My issue here is that this doesn't scale. Instead, the generic device attribute should only use a key lookup to find the value. If someone wants to create a more specialized attribute that contains L1, L2... they should be the ones adding those methods.


> Yes, this is currently missing. I am working on updating the system description to contain entries as well.

Cool!

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