Thanks for the feedback! Just to offer further insight fot @mehdi_amini , this tool works at the point of statically shape resolved TOSA form. It could handle dynamic shapes, but right now the focus is on emitting flatbuffer or JSON content to drive the TOSA reference model.
This enables bit-accuracy conformance testing, which enables the development or updation of current legalizations, a topic covered in the related thread - TOSA shape inference and dynamic shape support - #4 by sjarus .
This pass is the last remaining piece to get out in order to enable the open sourcing the TOSA legalization unit test infrastructure , which can be run any time the TF/TFLite to TOSA legalizations are updated. It would validate the the legalizations aren’t breaking anything in terms of functionality / bit accuracy.
The C++ interfaces here (and even the Python ones) are pretty stable, and have been so since back when we open sourced the reference model back in Nov 2020. The same serialization_lib repo is a dependency of both this translator (TOSA producer) and reference_model (TOSA consumer).
The tricky part here really is that this tool ought to be either standalone or pluggable into Bazel or CMake based flows we have. As an MLIR pass, this works well. For example, we’ve trivially added this into tf-opt. It’s been added to other internal flows targeting other frontends and backends.
It would also be valuable within any TOSA-consuming flow including IREE, which could trigger the flatbuffers generation and call the reference model to emit output to validate against codegen result, for example.
Given the conversation here, it probably makes better sense to wrap the pass into its own binary for the LLVM integration, but also optionally enable it to be integrated as a pass into any other flow. I’ll step back and take a stab at that now.