I’ve been trying to address an issue we have with the TensorFlow dialect, but that may apply to other domain as well related to the implicit propagation of dialect attributes.
In TensorFlow, every operation can have an optional device attribute. It isn’t an attribute defined by the operations themselves and it isn’t a property of each operation in particular. Such attributes aren’t exposed through ODS generated accessor and aren’t managed directly in DRR. As such any transformation as simple as the canonicalization of tf.Add into tf.AddV2 will drop the device attribute.
This is particularly limiting as right now we can’t always convert a TensorFlow graph into MLIR, canonicalize it, and convert it back to a TensorFlow graph that can be executed: preserving some attributes is unfortunately important for some test cases.
I wrote a simple DialectInterface for Attribute Propagation, which allows dialect to control the propagation of dialect attributes.
The hook signature is simply
void propagateAttribute(NamedAttribute attr, Operation *op) ; it is invoked after creating a new operation
op with a
NamedAttribute for this dialect (we lookup based on the key, so for TensorFlow we would have the attribute look like
tf.device = "...").
For interacting seamlessly with any kind of pattern rewrites, we augment the
OpBuilder with an optional
DictionaryAttribute. Every time an operation is created with the builder, the dictionary is iterated on and each matching attribute is dispatched to the interface with the created operation.
DictionaryAttribute can be manually set on the builder by a transformation, but it is automatically set to the current dictionary for an operation when the
OpBuilder is constructed from an existing
Operation. The driver for apply pattern will also set this dictionary to the root operation matched by the framework. As such every existing pattern will consider by default to propagate the attributes from the root operation (the implementation of the pattern can override this by resetting the dictionary on the provider
Feel free to check the revision I linked above (D95394) with an example in the