[all-commits] [llvm/llvm-project] 5ce4c9: [mlgo] Use TFLite for 'development' mode.

[Mircea Trofin via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 5ce4c9aa0405bb28dbe374aa741044025d63f05c
      https://github.com/llvm/llvm-project/commit/5ce4c9aa0405bb28dbe374aa741044025d63f05c
  Author: Mircea Trofin <mtrofin at google.com>
  Date:   2022-08-24 (Wed, 24 Aug 2022)

  Changed paths:
    M llvm/CMakeLists.txt
    M llvm/cmake/modules/TensorFlowCompile.cmake
    M llvm/include/llvm/Config/llvm-config.h.cmake
    M llvm/lib/Analysis/CMakeLists.txt
    A llvm/lib/Analysis/TFLiteUtils.cpp
    M llvm/lib/Analysis/TFUtils.cpp
    A llvm/lib/Analysis/models/saved-model-to-tflite.py
    M llvm/test/CodeGen/MLRegalloc/dev-mode-log-2-fcts.ll
    M llvm/test/CodeGen/MLRegalloc/dev-mode-logging.ll
    M llvm/test/CodeGen/MLRegalloc/dev-rel-equivalence.ll
    M llvm/test/Transforms/Inline/ML/bounds-checks-rewards.ll
    M llvm/test/Transforms/Inline/ML/development-training-log.ll
    M llvm/test/Transforms/Inline/ML/ml-test-development-mode.ll
    A llvm/unittests/Analysis/Inputs/ir2native_x86_64_model/model.tflite
    M llvm/unittests/Analysis/TFUtilsTest.cpp
    M utils/bazel/llvm_configs/llvm-config.h.cmake

  Log Message:
  -----------
  [mlgo] Use TFLite for 'development' mode.

TLite is a lightweight, statically linkable[1], model evaluator, supporting a
subset of what the full tensorflow library does, sufficient for the
types of scenarios we envision having. It is also faster.

We still use saved models as "source of truth" - 'release' mode's AOT
starts from a saved model; and the ML training side operates in terms of
saved models.

Using TFLite solves the following problems compared to using the full TF
C API:

- a compiler-friendly implementation for runtime-loadable (as opposed
  to AOT-embedded) models: it's statically linked; it can be built via
  cmake;
- solves an issue we had when building the compiler with both AOT and
  full TF C API support, whereby, due to a packaging issue on the TF
  side, we needed to have the pip package and the TF C API library at
  the same version. We have no such constraints now.

The main liability is it supporting a subset of what the full TF
framework does. We do not expect that to cause an issue, but should that
be the case, we can always revert back to using the full framework
(after also figuring out a way to address the problems that motivated
the move to TFLite).

Details:

This change switches the development mode to TFLite. Models are still
expected to be placed in a directory - i.e. the parameters to clang
don't change; what changes is the directory content: we still need
an `output_spec.json` file; but instead of the saved_model protobuf and
the `variables` directory, we now just have one file, `model.tflite`.

The change includes a utility showing how to take a saved model and
convert it to TFLite, which it uses for testing.

The full TF implementation can still be built (not side-by-side). We
intend to remove it shortly, after patching downstream dependencies. The
build behavior, however, prioritizes TFLite - i.e. trying to enable both
full TF C API and TFLite will just pick TFLite.

[1] thanks to @petrhosek's changes to TFLite's cmake support and its deps!