On querying an Operation's intrinsic (core) vs external/user-defined attributes

MLIR
6

Hi Chris,

My original post was focused purely on replacements where you replace an op of OpTy with another op of the same OpTy - sorry, if it didn’t make that clear. This is the scenario encountered in the PR https://reviews.llvm.org/D111837 On this PR, @mehdi_amini states:
“the safe things generic transformations should do is discard unknown attributes.”

And I would argue the other way that in the above scenario, the safe or safer thing is to propagate attributes as is.

  1. Note that when you have a folding hook or a rewrite/transformation that is updating an op in-place, you never check (and wouldn’t want to) as to what external attributes the op has and drop them. All in-place fold hooks and perhaps all rewrites in MLIR where this happens just update the op in-place when they have to. So, we are already implicitly propagating any external/user-defined attributes on in-place rewriting. Stating that you’d want to do something different when it’s a replacement in a canonicalization pattern or another utility is inconsistent with the former pervasive behavior. How do you reconcile the two?

  2. In the above scenario of replacement, if one argues that propagating external attributes is unsafe, one could argue that dropping them is more unsafe. In order to propagate them during replacement, we need a hook to get hold of the external attributes. This is also useful in other cases where it’s not a 1:1 replacement but the author of the rewrite knows it’s safe to propagate. (Perhaps this is what you referred to earlier.)

  3. If all else is the same on safety, propagating prevents loss of information and provides the desired functionality to pass pipeline developers who are using these external attributes to propagate short-lived information. The risks of using external attributes unknown to utilities are already clear to developers: there shouldn’t be any surprises if they are propagated like in the scf.for rewrite above. This is also consistent with everything else already happening during in-place update of ops.

Let’s try to resolve https://reviews.llvm.org/D111837 before a more general discussion on attribute propagation.