[Mlir-commits] [mlir] [MLIR][DLTI] Enable types as keys in DLTI-query utils (PR #105995)

[Rolf Morel]

rolfmorel wrote:

To me there are two main arguments for wanting this:

1. Data layout entry keys _are_ either `StrAttr`s or `Type`s, for over three years. Given that, why not allow the query mechanism to work with any key it could encounter. There are a number of upstream test cases (from before I touched DLTI) where a type is a key of a `#dlti.dl_entry` (e.g. do a search for `#dlti.dl_entry<i` or `#dlti.dl_entry<f`).

2. The `DataLayout` class of DLTI has functions like `Attribute getEndianness()` and `uint64_t getStackAlignment()` that get mirrored on `DataLayoutSpecAttr` as lookups on lists of `#dlti.dl_entry`s with the corresponding keys, in this case `"dlti.endianness"` and  `"dlti.stack_alignment"`. Missing from `DataLayoutSpecAttr` are lookups for the DataLayout functions like `llvm::TypeSize getTypeSize(Type t)` and `uint64_t getTypePreferredAlignment(Type t)`. These could be implemented as nested lookups on DLTI attributes, with the first key the type and the second key the property's name (e.g. `"dlti.type_size"` and `"dlti.preferred_alignment"`) or vice versa.
In general, I would like for properties of types to be easily encodable in the DLTI attributes, e.g. as `#dlti.map<#dlti.dl_entry<#my_dialect.special_vec<16xf32>, #dlti.map<#dlti.dl_entry<"strided", 4: i64>>>>`, to facilitate developing cost models that might want to depend on particular properties of particular types, especially while they are under development.



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