# TF Lite quantized conv2d operator conversion

**URL:** <https://discuss.tvm.apache.org/t/tf-lite-quantized-conv2d-operator-conversion/2651>\
**Category:** Questions\
**Created:** [May 21, 2019, 12:00am UTC](https://discuss.tvm.apache.org/t/tf-lite-quantized-conv2d-operator-conversion/2651 "2019-05-21T00:00:08Z")\
**Posts on this page:** 1\
**Showing post:** 11

<div class="post-metadata">

**Author:** ![FrozenGene](https://discuss.tvm.apache.org/user_avatar/discuss.tvm.apache.org/frozengene/32/1114_2.png) [@FrozenGene](https://discuss.tvm.apache.org/u/FrozenGene)\
**Post date:** [May 22, 2019, 9:49am UTC](https://discuss.tvm.apache.org/t/tf-lite-quantized-conv2d-operator-conversion/2651/11 "2019-05-22T09:49:46Z")

</div>

In fact, on ARM CPU, if want to produce VMLAL, normal way can not complete. i.e. Option 1 / 2 both can not do. Because ARM CPU only support int16-\>int32 VMLAL. So we have to tensorize. i.e. LOAD 8 elements U8 and convert to INT16, SUB zero\_point, then compute, finally we can leverage VMLAL. Option 1 maybe suit for VNNI instruction on Intel CPU.

Maybe I prefer Option 2. i.e. we provide standard / normal spatial\_pack schedule on ARM CPU / Intel CPU, and . on generic target (i.e. nn.py), we provide `q_conv2d`'s compute in naive way. Spatial pack schedule performs well in fact according to our test and implement it very easily. But if you want to improve, you could write tensorize version for your target. For example, to produce ARM CPU’s VMLAL / Intel’s VNNI.

---

_[View the full topic](https://discuss.tvm.apache.org/t/tf-lite-quantized-conv2d-operator-conversion/2651)._