[RtInfo/IR] Serialize non RuntimeAttribute rt_info entries of Node and Tensor

[t-jankowski]

Details:

• Adds into pass::Serialize and IR FE support for non RuntimeAttribute entries from rt_info map of ov::Node and ov::Tensor

Tickets:

• CVS-156284

[itikhono]

What is the purpose of implementing this solution?
What task are we solving, for which models?

[t-jankowski]

What is the purpose of implementing this solution? What task are we solving, for which models?

It's related to CVS-105807 and CVS-105845.

[ilya-lavrenov]

will it affect model caching?
E.g. more attributes affects hash of serialized representation

[t-jankowski]

will it affect model caching? E.g. more attributes affects hash of serialized representation

Yes, current solution in this PR affects pass::Hash. These new entries would undergo deterministic mode to not affect hash.

Other case to consider is that there is no black list (rt_map entries not to be serialized), so currently all are serialized.

@ilya-lavrenov @slyalin please advise.

[slyalin]

@t-jankowski , what kind of advice you need? The purpose of this PR as I understood it, is to provide a reliable tool for developers who are crafting and annotating models in run-time. For those people, the reasonable debug flow is handy -- if you serialize such a model you want to see what you have done with the graph, including rt_info. And then you should be able to read such IR back into run-time without losing the information. Otherwise, this serialize/deserialize flow is broken. The requirement to build serializable attributes with RuntimeAttribute brakes the flow for such external developers without providing any extra value -- it didn't work for Python for example. The purpose of this PR is not to expose more rt_info attributes automatically -- all kind of "regularly" created rt_info should be under the full control and should be analyzed and understood in respect of affecting everything else including hashing etc. It is mostly related to p.p 3-7 from CVS-105807 in terms of improvements. If the current solution in this PR breaks our expectations for hashing (and I don't understand how) or have other impacts then it should be improved.

[github-actions]

This PR will be closed in a week because of 2 weeks of no activity.