[Relay][Frontend] Adding ADD operator to tflite frontend for compiling the MobileNetV2

[gomida]

• Adding ADD operator to tflite frontend for compiling the MobileNetV2
• Adding TestCase

[FrozenGene]

LGTM. @gomida Thanks for your contribution.

[gomida]

Hi @FrozenGene do I need to request review to additional member?

[FrozenGene]

@srkreddy1238 Pls help to review.

[srkreddy1238]

LGTM . Thanks.

[FrozenGene]

@gomida Sorry to disturb you. However, maybe I find one potential issue we didn't consider in code. Let us imagine the LHS shape is not the same as RHS shape. For example, TFLite input layout is [1, 16, 32, 180], RHS shape is [180]. Then we should got [1, 16, 32, 180]. However, we transpose input layout be [1, 180, 16, 32], then RHS shape is [180]. In code, we just pass this condition. So we gout [1, 180, 16, 32] + [180], which couldn't do broadcast.

One way to solve is:

• Transpose LHS be NHWC
• Keep RHS be the same
• Call _op.add
• Transpose back to NCHW.

My origin plan is to support TFLite NHWC data layout as #2519 described after my quantization part is upstreamed done. However, if you are interested to support it , also welcome. It shouldn't be difficult.

[gomida]

@FrozenGene sure, I'll look into the issue :)

[gomida]

@FrozenGene during test, I found some more problems. We've assumed that the LHS as tensor, but in some cases, the LHS may not be a tensor (in this case the RHS is a tensor). This requires some more complex handling. On the other hand, changing the layout to the original NHWC will add many transpose layers and make it as slow as the imported TF models - not an easy decision because we have no "automatic layout conversion pass" mentioned in #2519 currently.

[FrozenGene]

@gomida Could you give example / model when we have the case of LHS is constant values? During model testing, I only meet LHS is tensor and RHS is constant condition.

The performance shouldn't be problem. Because we will fuse these transpose ops and the add / transpose ops run very fast, and the model will not have many add ops.

Additionally, I plan to support TFLite NHWC data layout and implement spatial pack NHWC schedule on ARM CPU firstly after my quantization part is upstreamed. Currently, we don't have spatial pack NHWC optimization on ARM CPU, which is the main platform we will run TFLite model . I don't know whether you are interested in supporting NHWC layout of TFLite, if you do, welcome to open RFC issue and contribute.