[NFC][mlgo] Fix imports post- PR#97023

[mlgo] remove `inlining_default` - unused feature

The feature was only exposed for training and was immediately dropped on
the training side. It was bulk-copied into the test model generator, where

[mlgo] remove `inlining_default` - unused feature

The feature was only exposed for training and was immediately dropped on
the training side. It was bulk-copied into the test model generator, where
it had no effect (the generator always returns a constant).

In the AOT + test model case, since the test model returns a constant, all
input features are pruned by the AOT compiler, so its presence/absence
doesn't matter.

show more ...

[mlgo][nfc] Remove / fix vestigial references to Tensorflow

Some references in comments are unnecessarily specific, for historical reasons.

[mlgo][inl] Interactive mode: optionally tell the default decision

This helps training algorithms that may want to sometimes replicate the
default decision. The default decision is presented as an e

[mlgo][inl] Interactive mode: optionally tell the default decision

This helps training algorithms that may want to sometimes replicate the
default decision. The default decision is presented as an extra feature
called `inlining_default`. It's not normally exported to save
computation time.

This is only available in interactive mode.

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

show more ...

Reland "[mlgo] Hook up the interactive runner to the mlgo-ed passes"

This reverts commit a772f0bb920a4957fb94dd8dbe45943809fd0ec3.

The main problem was related to how we handled `dbgs()` from the h

Reland "[mlgo] Hook up the interactive runner to the mlgo-ed passes"

This reverts commit a772f0bb920a4957fb94dd8dbe45943809fd0ec3.

The main problem was related to how we handled `dbgs()` from the hosted
compiler. Using explicit `subprocess.communicate`, and not relying on
dbgs() being flushed until the end appears to address the problem.

Also some fixes due to some bots running older pythons, so we can't have
nice things like `int | float` and such.

show more ...

Revert "[mlgo] Hook up the interactive runner to the mlgo-ed passes"

This reverts commit a7354899d1a235a796b3a2ccb45f6596983c8672.

The way stdout/stderr get routed seems to work differently locally

Revert "[mlgo] Hook up the interactive runner to the mlgo-ed passes"

This reverts commit a7354899d1a235a796b3a2ccb45f6596983c8672.

The way stdout/stderr get routed seems to work differently locally and
on the bots. Investigating.

show more ...

[mlgo] Hook up the interactive runner to the mlgo-ed passes

This hooks up the interactive model runner to the passes that support
ml-based decisions. Because the interface to this runner is the exac

[mlgo] Hook up the interactive runner to the mlgo-ed passes

This hooks up the interactive model runner to the passes that support
ml-based decisions. Because the interface to this runner is the exact
same as the one used during inference, we just reuse the exact same
setup we have for "release mode". This makes "release mode" a misnomer -
and that's something we needed to resolve sooner or later (e.g.
supporting more than one embedded model for the same problem was another
reason to drop that nomenclature). That will happen in a subsequent
change.

To use this evaluator, just enable the pass in (currently) "release"
mode, but also pass the base name for the 2 channel files via the
pass-specific flag.

The 2 files are the responsibilty of the hosting process. The added
tests use a minimal, toy such host, illustrating setup and
communication.

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

show more ...

[mlgo] Stream the training data

This leverages the new logging format in that we don't need to buffer
the training data, we can just write it out.

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

[mlgo] Stream the training data

This leverages the new logging format in that we don't need to buffer
the training data, we can just write it out.

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

show more ...

[mlgo] Remove the protobuf dependency

The dependency was due to the log format. This change switches to the
previously-introduced (D139370) "dependency-free" logger instead of the
protobuf-based one

[mlgo] Remove the protobuf dependency

The dependency was due to the log format. This change switches to the
previously-introduced (D139370) "dependency-free" logger instead of the
protobuf-based one.

A subsequent change will clean out the unnecessary abstraction left
behind.

This change drops the logger unittest, we have sufficient test coverage
via lit tests, and a unit test would require adding, unnecesarily, a log
reader (the reader is expected to be python, for the ML side, and there
is a reader for that under Analysis/models, used for tests).

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

show more ...

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

[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 ...

[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 ...

[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 ...

[nfc][mlgo] Separate logger and training-mode model evaluator

This just shuffles implementations and declarations around. Now the
logger and the TF C API-based model evaluator are separate.

Differe

[nfc][mlgo] Separate logger and training-mode model evaluator

This just shuffles implementations and declarations around. Now the
logger and the TF C API-based model evaluator are separate.

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

show more ...

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

This allows the compiler to support more features than those supported by a
model. The only requirement (development mode only) i

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

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

show more ...

Cleanup includes: DebugInfo & CodeGen

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D121332

[llvm] Remove uses of `std::vector<bool>`

LLVM Programmer’s Manual strongly discourages the use of `std::vector<bool>` and suggests `llvm::BitVector` as a possible replacement.

This patch does just

[llvm] Remove uses of `std::vector<bool>`

LLVM Programmer’s Manual strongly discourages the use of `std::vector<bool>` and suggests `llvm::BitVector` as a possible replacement.

This patch does just that for llvm.

Reviewed By: dexonsmith

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

show more ...

[NFC][MLGO] Use LazyCallGraph::Node to track functions.

This avoids the InlineAdvisor carrying the responsibility of deleting
Function objects. We use LazyCallGraph::Node objects instead, which are

[NFC][MLGO] Use LazyCallGraph::Node to track functions.

This avoids the InlineAdvisor carrying the responsibility of deleting
Function objects. We use LazyCallGraph::Node objects instead, which are
stable in memory for the duration of the Module-wide performance of CGSCC
passes started under the same ModuleToPostOrderCGSCCPassAdaptor (which
is the case here)

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

show more ...

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

[NFC][MLGO] Factor ModelUnderTrainingRunner for reuse

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

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

[NFC][mlgo] Generalize model runner interface

This prepares it for the regalloc work. Part of it is making model
evaluation accross 'development' and 'release' scenarios more reusable.
This patch:
-

[NFC][mlgo] Generalize model runner interface

This prepares it for the regalloc work. Part of it is making model
evaluation accross 'development' and 'release' scenarios more reusable.
This patch:
- extends support to tensors of any shape (not just scalars, like we had
in the inliner -Oz case). While the tensor shape can be anything, we
assume row-major layout and expose the tensor as a buffer.
- exposes the NoInferenceModelRunner, which we use in the 'development'
mode to keep the evaluation code path consistent and simplify logging,
as we'll want to reuse it in the regalloc case.

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

show more ...

[MLGO] Make sure inliner logs when deleting callees

When using final reward (which is now the default), we were skipping
logging decisions that were leading to callee deletion. This fixes that.

Dif

[MLGO] Make sure inliner logs when deleting callees

When using final reward (which is now the default), we were skipping
logging decisions that were leading to callee deletion. This fixes that.

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

show more ...

[llvm][clang][NFC] updates inline licence info

Some files still contained the old University of Illinois Open Source
Licence header. This patch replaces that with the Apache 2 with LLVM
Exception li

[llvm][clang][NFC] updates inline licence info

Some files still contained the old University of Illinois Open Source
Licence header. This patch replaces that with the Apache 2 with LLVM
Exception licence.

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

show more ...

[NFC][MLGO] Make logging more robust

1) add some self-diagnosis (when asserts are enabled) to check that all
features have the same nr of entries

2) avoid storing pointers to mutable fields because

[NFC][MLGO] Make logging more robust

1) add some self-diagnosis (when asserts are enabled) to check that all
features have the same nr of entries

2) avoid storing pointers to mutable fields because the proto API
contract doesn't actually guarantee those stay fixed even if no further
mutation of the object occurs.

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

show more ...

[NFC][MLGO] Just use the underlying protobuf object for logging

Avoid buffering just to copy the buffered data, in 'development
mode', when logging. Instead, just populate the underlying protobuf.

[NFC][MLGO] Just use the underlying protobuf object for logging

Avoid buffering just to copy the buffered data, in 'development
mode', when logging. Instead, just populate the underlying protobuf.

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

show more ...