llvm-project.git/llvm/lib/Analysis/ModelUnderTrainingRunner.cpp, branch main

[Analysis] llvm::Optional => std::optional

2022-12-14T07:32:24+00:00

[mlgo] Use LLVM_HAVE_TFLITE instead of LLVM_HAVE_TF_API in C++ code (NFC)

2022-12-12T19:28:40+00:00

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

[llvm] Use std::nullopt instead of None (NFC)

2022-12-10T02:32:32+00:00

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

[mlgo][nfc] Make `LoggedFeatureSpec` an implementation detail

2022-11-30T23:57:58+00:00

It's an artifact very specific to using TFAgents during training, so it
belongs with ModelUnderTrainingRunner.

Differential Revision: https://reviews.llvm.org/D139031

[MLGO] Fix InlineAdvisor and ModelUnderTrainingRunner after hasValue removal

2022-11-24T03:48:34+00:00

Recentlyin 4b6b248, llvm::Optional's hasValue method was removed as
described in
https://discourse.llvm.org/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor
This breaks InlineAdvisor and ModelUnderTrainingRunner. This patch fixes
them by changing the method to has_value, which hasValue was evaluating
to before.

Differential Revision: https://reviews.llvm.org/D138635

[iwyu] Handle regressions in libLLVM header include

2022-05-26T06:12:34+00:00

Running iwyu-diff on LLVM codebase since 7030654296a0416bd9402a0278 detected a few
regressions, fixing them.

Differential Revision: https://reviews.llvm.org/D126417

[mlgo] Support exposing more features than those supported by models

2022-05-10T01:01:21+00:00

This allows the compiler to support more features than those supported by a
model. The only requirement (development mode only) is that the new
features must be appended at the end of the list of features requested
from the model. The support is transparent to compiler code: for
unsupported features, we provide a valid buffer to copy their values;
it's just that this buffer is disconnected from the model, so insofar
as the model is concerned (AOT or development mode), these features don't
exist. The buffers are allocated at setup - meaning, at steady state,
there is no extra allocation (maintaining the current invariant). These
buffers has 2 roles: one, keep the compiler code simple. Second, allow
logging their values in development mode. The latter allows retraining
a model supporting the larger feature set starting from traces produced
with the old model.

For release mode (AOT-ed models), this decouples compiler evolution from
model evolution, which we want in scenarios where the toolchain is
frequently rebuilt and redeployed: we can first deploy the new features,
and continue working with the older model, until a new model is made
available, which can then be picked up the next time the compiler is built.

Differential Revision: https://reviews.llvm.org/D124565

[NFC][MLGO] Remove the word "inliner" in a generic error message.

2022-01-11T20:39:16+00:00

[NFC][MLGO]Add RTTI support for MLModelRunner and simplify runner setup

2022-01-05T03:46:14+00:00

[NFC][MLGO] Factor ModelUnderTrainingRunner for reuse

2021-12-10T19:24:15+00:00

This is so we may reuse it. It was very non-inliner specific already.

Differential Revision: https://reviews.llvm.org/D115465