[all-commits] [llvm/llvm-project] 5ce4c9: [mlgo] Use TFLite for 'development' mode.
Mircea Trofin via All-commits
all-commits at lists.llvm.org
Wed Aug 24 16:07:56 PDT 2022
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!
More information about the All-commits
mailing list