Compiler FE: Upgrade to TF 2.6.0

[seanshpark]

Let's upgrade TF 2.3.0 to TF 2.6.0 for tflite2circle and related modules.

After this task is finished,

• enable to use SignatureDef to fix index changes

[seanshpark]

Previois related task: #7592 (comment)

[llFreetimell]

To correctly support TFLite 2.6.0, following things should be considered and updated too.

• Compiler FE: TF 2.4 version upgrade #5688 (comment)
• TFLite related modules in [Draft] Schema update for compiler #6269

[llFreetimell]

By the way, can I ask you why mio-tflite260 is introduced?
At first, I thought following steps.

• Introduce mio-tflite260 which uses TF 2.6.0
• Update tflite schame related functions in each module by using mio-tflite260
  • For example,

    ONE/compiler/tfl-inspect/src/Reader.cpp

    Lines 27 to 28 in f829125

    	tflite::BuiltinOperator code = opcode->builtin_code();
    	int8_t deprecated_code = opcode->deprecated_builtin_code();

• After tflite schema changes are applied to all of modules, deprecate mio-tflite
• Change mio-tflite260 to mio-tflite

But current workflows are quite different and thus changes across different modules are inevitable in the near future I think.
So I was curious why mio-tflite260 is introduced.

[seanshpark]

By the way, can I ask you why mio-tflite260 is introduced?

Your thoughts are similar what I'm working on. mio-tflite may exist if there exist modules use it.

current workflows are quite different

What exactly are different?

[llFreetimell]

mio-tflite may exist if there exist modules use it.

As TFLite keeps backward compatibility, I think we don't need both 2.3.0 and 2.6.0 schema.
Only with 2.6.0 schema, we can support them all.

What exactly are different?

For now, mio-tflite260 uses 2.3.0 TF.
But if we update it to 2.6.0 later, all of current modules which are using mio-tflite260 must change their functions to read tflite file.
So current workflow is same as "Change mio-tflite to use 2.6.0 and change all the functions in related modules at the same time", not what I wrote.

[seanshpark]

I think we don't need both 2.3.0 and 2.6.0 schema.

I will let 2.3.0 exist if needed. I think this is the main part of difference.

But if we update it to 2.6.0 later,

Yes...

must change their functions to read tflite file.

I don't think it's a must. Can you share why you think so?

[llFreetimell]

exist if needed

I cannot imagine when both of them are needed because 2.6.0 schema can read all tflite files which are generated under 2.6.0 ....

I don't think it's a must. Can you share why you think so?

Hmm...? Without this, tflite file is not read correctly....
Both 2.3.0 and 2.6.0 hasbuiltin_code but position is different, this is one of the biggest update on TFLite schema.
Please refer to #5688 (comment) .

[seanshpark]

Both 2.3.0 and 2.6.0 hasbuiltin_code but position is different,

Ah, I got it...
Partial modules upgrade to 2.6.0 had some problem was related to this.
When I checked, only worked with when all modules where 2.6.0
This worked as all the modules and models was using new schema.
But this was incorrect case if any tflite model was from 2.3.0.

[seanshpark]

I cannot imagine when both of them are needed

Not needed but some modules will be left as-is (not sure they will actually exist)

[seanshpark]

18:08:24 [ RUN ] NET_0025
18:08:24 [ FAIL] NET_0025
18:08:24 /opt/jenkins_slave/workspace/nnfw/master/pr-nncc-debug/build/compiler/tf2tflite-dredd-pbtxt-test
18:08:24 FAILED
18:08:24 - NET_0025

tfldump result

Operator Codes: [order] OpCodeName (OpCode Enum)
[0] ADD (code: 0, version: 1)

TODO

1. check tf2tflite conversion
   • uses old tfkit...
   • we can leave it as-is, this will produce v3 format that can be used as old format
2. fix builtin_code reader
   • fix opcode reader

[seanshpark]

done