[tflchef] Support multiple subgraphs

[BalyshevArtem]

What

Let's support multiple subgraphs in tflchef-reverse

Why

To generate recipes for tflite models with multiple subgraphs (for example for #12319 (comment))

[seanshpark]

from #12516 (comment)

about the changes

1/ all the build() for ops have to be changed
-> current tflchef::ModelRecipe *model_recipe argument cannot add op for sub-graphs
-> protobuf was designed like this. there was only one sub-graph when reverse was introduced and then extended with adding Graph for multiple sub-graphs, thus add_operation() exist in tflchef::ModelRecipe and also tflchef::Graph.
-> this is technical-debt

2/ TFliteImport *import is not used for all build()
-> this turned out like build() method design was not good

requirements to support multiple sub-graph in recipe generation

1/ support adding new Op in tflchef::Graph
2/ do not change files in Op folder
-> this seems impossible as we have to call tflchef::Graph::add_operation() somehow
3/ reduce changes
4/ ...

what I can think of ...

as-is

tflchef::Operation *
build(const tflite::Operator *op, TFliteImport *import, tflchef::ModelRecipe *model_recipe) const

is called from

    if (const auto *graph_builder = TFliteOpRegistry::get().lookup(builtincode))
    {
      auto operation = graph_builder->build(op, &tflite_import, model_recipe.get());

prop 1: replace with new context class

tflchef::Operation *
build(const tflite::Operator *op, ChefContext *cctx) const
{
  auto operation = cctcx->add_operation();

prop 2: create tflchef::Operation object from caller and pass

void
build(const tflite::Operator *op, tflchef::Operation *op) const

call from

    if (const auto *graph_builder = TFliteOpRegistry::get().lookup(builtincode))
    {
      tflchef::Operation *operation = graph ? graph->add_operation() : model_recipe.add_operation();
      graph_builder->build(op, operation);

prop 3: ... will update if any other comes up

[mhs4670go]

There are two things that I came up with.

1. Revise existing proto file and all the recipe files accordingly.

message Graph {
  repeated Operand operand = 1;
  repeated Operation operation = 2;
  repeated string input = 3;
  repeated string output = 4;
  optional string name = 5;
}

message ModelRecipe {
  optional uint32 version = 1 [default = 1];
  repeated Graph graph = 2;
  repeated SignatureDef signature_def = 3;
}

2. Use c++ template feature

Since Modelrecipe api covers all the Graph api, template feature reduces otherwise required if condition.

[seanshpark]

Revise existing proto file and all the recipe files accordingly.

This will require all existing recipe files to be updated to follow the schema...

[BalyshevArtem]

prop 2: create tflchef::Operation object from caller and pass

I prefer this second variant, anyway, I can do any of them. Which one should I choose?

[seanshpark]

I prefer this second variant, anyway, I can do any of them. Which one should I choose?

first idea using ChefContext is that we won't have to change the build() prototype anymore
but to change ChefContext members when needed.

mixing them would be like

prop 3;

struct RecipeChefContext {
  tflite::Operator *tflop = nullptr;
  tflchef::Operation *chefop = nullptr;
  // add more if needed
};

void build(RecipeChefContext *ctx) const

[seanshpark]

Thanks for accepting my proposal and for laborious update!

[BalyshevArtem]

thank you @seanshpark!
All merged, close it.