Thank you very much for this detailed reply!



 Mehdi_AMINI:

Regardless, I’m not sure what is the problem you’re trying to solve with this?


The problem I am trying to solve is to implement a graph optimization pass based on TFG, similar to GSPMD 1 does for XLA. This optimization pass would add additional information to TFG’s node, and this information would be changed during the optimization process. This info could be something like “estimated split strategy for current op”. Let’s call this split_strategy for simplicity. I would wish this split_strategy flow through the whole graph, thus every op node would have this split_strategy.
To do that, I am looking forward to define a dialect called toy , this dialect is based on tfg, and it wraps mlir::TensorType to a toy::TensorType. This toy::TensorType would have an additional field split_strategy. This split_strategy would change frequently when searching for an optimal one. Thus recreating the node would be something too expensive.



 Mehdi_AMINI:

Types aren’t mutable, the exception you’re pointing at is only intended to be able to implement recursive types





 Mehdi_AMINI:

As mentioned above, you can’t change the content of an attribute in-place, but you swap individual attributes on an operation.


As you mentioned,  if the types are not mutable in general, then could you tell me a little more the use case of how to bind mutable information to the tfg tensor as an attribute?  I mean, could you give a little more hint on how to sway individual attributes? By defining the the attribute as a pointer?
I thought converting a mlir::ElementsAttr(tfg converted tensor type) to toy::TensorType (toy dialect converted from tfg) dialect and do whatever on that type is a a good choice.  If the mutable type is not intended , then what should I refer if I wish to frequently update information binded to an tensor attribute?
Thank you again for your help!