Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3 |
|
#
28bb2193 |
| 11-Oct-2023 |
Mircea Trofin <mtrofin@google.com> |
[mlgo][nfc] Remove / fix vestigial references to Tensorflow
Some references in comments are unnecessarily specific, for historical reasons.
|
Revision tags: llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7 |
|
#
d4b6fcb3 |
| 14-Dec-2022 |
Fangrui Song <i@maskray.me> |
[Analysis] llvm::Optional => std::optional
|
#
edc83a15 |
| 12-Dec-2022 |
Kazu Hirata <kazu@google.com> |
[mlgo] Use LLVM_HAVE_TFLITE instead of LLVM_HAVE_TF_API in C++ code (NFC)
We use LLVM_HAVE_TFLITE as the key to enable the mlgo work these days, and LLVM_HAVE_TF_API is defined whenever LLVM_HAVE_TF
[mlgo] Use LLVM_HAVE_TFLITE instead of LLVM_HAVE_TF_API in C++ code (NFC)
We use LLVM_HAVE_TFLITE as the key to enable the mlgo work these days, and LLVM_HAVE_TF_API is defined whenever LLVM_HAVE_TF_API is defined.
I'm posting this patch because it's purely mechanical.
I'll post a follow-up patch to remove LLVM_HAVE_TF_API in non-C++ files, and that will not be as mechanical as this one.
Differential Revision: https://reviews.llvm.org/D139863
show more ...
|
#
9c444f70 |
| 10-Dec-2022 |
Kazu Hirata <kazu@google.com> |
[llvm] Use std::nullopt instead of None (NFC)
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-g
[llvm] Use std::nullopt instead of None (NFC)
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
show more ...
|
#
1ee3bb17 |
| 30-Nov-2022 |
Mircea Trofin <mtrofin@google.com> |
[mlgo][nfc] Make `LoggedFeatureSpec` an implementation detail
It's an artifact very specific to using TFAgents during training, so it belongs with ModelUnderTrainingRunner.
Differential Revision: h
[mlgo][nfc] Make `LoggedFeatureSpec` an implementation detail
It's an artifact very specific to using TFAgents during training, so it belongs with ModelUnderTrainingRunner.
Differential Revision: https://reviews.llvm.org/D139031
show more ...
|
Revision tags: llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3 |
|
#
17095dfe |
| 12-Oct-2022 |
Jacob Hegna <jacobhegna@google.com> |
Move interpreter check before modifying the allocation type.
|
#
9d93a98f |
| 12-Oct-2022 |
Jacob Hegna <jacobhegna@google.com> |
[MLGO] Force persistency in tflite buffers.
When training large models, we encounter use-after-free bugs when writing to the input tensors for various MLGO models. This patch fixes the issue by mark
[MLGO] Force persistency in tflite buffers.
When training large models, we encounter use-after-free bugs when writing to the input tensors for various MLGO models. This patch fixes the issue by marking the tensors as "persistent".
Differential Revision: https://reviews.llvm.org/D135739
show more ...
|
Revision tags: working, llvmorg-15.0.2, llvmorg-15.0.1 |
|
#
ec83c7e3 |
| 07-Sep-2022 |
Aiden Grossman <agrossman154@yahoo.com> |
[MLGO] Make TFLiteUtils throw an error if some features haven't been passed to the model
In the Tensorflow C lib utilities, an error gets thrown if some features haven't gotten passed into the model
[MLGO] Make TFLiteUtils throw an error if some features haven't been passed to the model
In the Tensorflow C lib utilities, an error gets thrown if some features haven't gotten passed into the model (due to differences in ordering which now don't exist with the transition to TFLite). However, this is not currently the case when using TFLiteUtils. This patch makes some minor changes to throw an error when not all inputs of the model have been passed, which when not handled will result in a seg fault within TFLite.
Reviewed By: mtrofin
Differential Revision: https://reviews.llvm.org/D133451
show more ...
|
#
a219a8a8 |
| 08-Sep-2022 |
Mircea Trofin <mtrofin@google.com> |
[mlgo][nfc] Set logging level to warning or higher for TFLite
|
Revision tags: llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2 |
|
#
5ce4c9aa |
| 06-Aug-2022 |
Mircea Trofin <mtrofin@google.com> |
[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 s
[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!
show more ...
|