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

Rolf Morel llvmlistbot at llvm.org
Mon Aug 26 04:28:51 PDT 2024


================
@@ -424,8 +424,8 @@ getClosestQueryable(Operation *op) {
   return std::pair(queryable, op);
 }
 
-FailureOr<Attribute> dlti::query(Operation *op, ArrayRef<StringAttr> keys,
-                                 bool emitError) {
+FailureOr<Attribute>
+dlti::query(Operation *op, ArrayRef<DataLayoutEntryKey> keys, bool emitError) {
----------------
rolfmorel wrote:

At the moment an empty `keys` would return the DLTI attribute that is closest to `op`, if such an attribute exists. This behaviour might be useful/desirable - you could then work directly with that attribute, for example. 

A reason this behaviour might be less desirable is that we would like to implement shadowing, i.e. `dlti::query` would in try all DLTI attributes that are attached to ancestors of `op` in turn, until one can provide a value for `keys`. In that case an empty `keys` would more naturally correspond to a queryable object which would provide the same lookup capability, i.e. would delegate key look ups to the same underlying attributes.

In the absence of a strong argument for what should be returned, I am inclined to just disallow empty `keys` for now. I am fine with doing it in this PR, or else I would address it when I do the shadowing work.

Let me know what you feel would be best.

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


More information about the Mlir-commits mailing list