It isn’t tailored to a specific kind of effects, that’s why it uses the generic attribute representation. I believe there was a discussion about that, but can seem to find it anymore. Could have been an ODM or something like that though.
That’s a good fit IMO, side effect parameters aren’t extensively utilized in upstream dialects, if at all. Let’s put them to use. If this becomes a performance issue due to memory indirections via attribute storage, it still looks possible to reconsider later on or address the actual problem.
I think it will be better option for the community to expose the parameters in ODS. Thus, if somebody wants to use it for something else than ordering the effects, they will be able to. Note that the attribute name isn’t necessary. The parameter is just an attribute and isn’t stored in a dictionary, unlike the in an op. We should think about the case when there are multiple parameters, which can be solved by either having a dictionary attribute with names as the top-level parameter, or an array attribute with attributes of distinct types, or something else. I am slightly in favor of the second approach with defining a specific SideEffectOrderAttr, which would be also easily visible in ODS.