[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