| Age | Commit message (Collapse) | Author |
|---|
|
This PR restructures the vocabulary.
* String based look-ups are removed. Vocabulary is changed from a map to vector. (#141832)
* Grouped all the vocabulary related methods under a single class - `ir2vec::Vocabulary`. This replaces `IR2VecVocabResult`.
* `ir2vec::Vocabulary` effectively abstracts out the _layout_ and other internal details of the vector structure. Exposes necessary APIs for accessing the Vocabulary.
These changes ensure that _all_ known opcodes and types are present in the vocabulary. We have retained the original operands. This can be extended going forward.
(Tracking issue - #141817)
|
|
This change simplifies the API by removing the error handling complexity.
- Changed `Embedder::create()` to return `std::unique_ptr<Embedder>` directly instead of `Expected<std::unique_ptr<Embedder>>`
- Updated documentation and tests to reflect the new API
- Added death test for invalid IR2Vec kind in debug mode
- In release mode, simply returns nullptr for invalid kinds instead of creating an error
(Tracking issue - #141817)
|
|
Relanding #143479 after fixes.
Removed `NumberOfFeatures` from the `FeatureIndex` enum as the number of features used depends on whether IR2Vec embeddings are used.
|
|
This reverts commit af2c06ecd610735dfa5d236c6d5f109e4f2334e6 as it
causes failure of lit test (Transforms/Inline/ML/interactive-mode.ll)
|
|
Changes to use Symbolic embeddings in MLInliner.
(Fixes #141836, Tracking issue - #141817)
|
|
## Purpose
This patch is one in a series of code-mods that annotate LLVM’s public
interface for export. This patch annotates the `llvm/Analysis` library.
These annotations currently have no meaningful impact on the LLVM build;
however, they are a prerequisite to support an LLVM Windows DLL (shared
library) build.
## Background
This effort is tracked in #109483. Additional context is provided in
[this
discourse](https://discourse.llvm.org/t/psa-annotating-llvm-public-interface/85307),
and documentation for `LLVM_ABI` and related annotations is found in the
LLVM repo
[here](https://github.com/llvm/llvm-project/blob/main/llvm/docs/InterfaceExportAnnotations.rst).
The bulk of these changes were generated automatically using the
[Interface Definition Scanner (IDS)](https://github.com/compnerd/ids)
tool, followed formatting with `git clang-format`.
The following manual adjustments were also applied after running IDS on
Linux:
- Add `#include "llvm/Support/Compiler.h"` to files where it was not
auto-added by IDS due to no pre-existing block of include statements.
- Add `LLVM_TEMPLATE_ABI` and `LLVM_EXPORT_TEMPLATE` to exported
instantiated templates
- Add `LLVM_ABI` to a subset of private class methods and fields that
require export
- Add `LLVM_ABI` to a small number of symbols that require export but
are not declared in headers
## Validation
Local builds and tests to validate cross-platform compatibility. This
included llvm, clang, and lldb on the following configurations:
- Windows with MSVC
- Windows with Clang
- Linux with GCC
- Linux with Clang
- Darwin with Clang
|
|
We can use *Set::insert_range to collapse:
for (auto Elem : Range)
Set.insert(E);
down to:
Set.insert_range(Range);
In some cases, we can further fold that into the set declaration.
|
|
DenseSet, SmallPtrSet, SmallSet, SetVector, and StringSet recently
gained C++23-style insert_range. This patch uses insert_range in
conjunction with llvm::{predecessors,successors} and
MachineBasicBlock::{predecessors,successors}.
|
|
#125983
|
|
It's more clear. (This isn't exhaustive).
|
|
FunctionPropertiesAnalysis (#104867) (#106309)
Reverts c992690179eb5de6efe47d5c8f3a23f2302723f2.
The problem is that if there is a sequence "{delete A->B} {delete A->B}
{insert A->B}" the net result is "{delete A->B}", which is not what we
want.
Duplicate successors may happen in cases like switch statements (as
shown in the unit test).
The second problem was that in `invoke` cases, some edges we speculate may get deleted don't, but are also not reachable from the inlined call site's basic block. We just need to check which edges are actually not present anymore.
The fix is to sanitize the list of deletes, just like we do for inserts.
|
|
FunctionPropertiesAnalysis (#104867)"
This seems to cause asserts in our builds:
llvm/include/llvm/Support/GenericDomTreeConstruction.h:927:
static void llvm::DomTreeBuilder::SemiNCAInfo<llvm::DominatorTreeBase<BasicBlock, false>>::DeleteEdge(DomTreeT &, const BatchUpdatePtr, const NodePtr, const NodePtr) [DomTreeT = llvm::DominatorTreeBase<BasicBlock, false>]:
Assertion `!IsSuccessor(To, From) && "Deleted edge still exists in the CFG!"' failed.
and
llvm/lib/Analysis/FunctionPropertiesAnalysis.cpp:390:
DominatorTree &llvm::FunctionPropertiesUpdater::getUpdatedDominatorTree(FunctionAnalysisManager &) const:
Assertion `DT.getNode(BB)' failed.
See comment on the PR.
> We need the dominator tree analysis for loop info analysis, which we need to get features like most nested loop and number of top level loops. Invalidating and recomputing these from scratch after each successful inlining can sometimes lead to lengthy compile times. We don't need to recompute from scratch, though, since we have some boundary information about where the changes to the CFG happen; moreover, for dom tree, the API supports incrementally updating the analysis result.
>
> This change addresses the dom tree part. The loop info is still recomputed from scratch. This does reduce the compile time quite significantly already, though (~5x in a specific case)
>
> The loop info change might be more involved and would follow in a subsequent PR.
This reverts commit a2a5508bdae7d115b6c3ace461beb7a987a44407 and the
follow-up commit cdd11d694a406a98a16d6265168ee2fbe1b6a87c.
|
|
An assert was left over after addressing feedback. In the process of
fixing, realized the way I addressed the feedback was also incomplete.
|
|
FunctionPropertiesAnalysis (#104867)
We need the dominator tree analysis for loop info analysis, which we need to get features like most nested loop and number of top level loops. Invalidating and recomputing these from scratch after each successful inlining can sometimes lead to lengthy compile times. We don't need to recompute from scratch, though, since we have some boundary information about where the changes to the CFG happen; moreover, for dom tree, the API supports incrementally updating the analysis result.
This change addresses the dom tree part. The loop info is still recomputed from scratch. This does reduce the compile time quite significantly already, though (~5x in a specific case)
The loop info change might be more involved and would follow in a subsequent PR.
|
|
Namespaces are terminated with a closing comment in the majority of the
codebase so do the same here for consistency. Also format code within
some namespaces to make clang-format happy.
|
|
|
|
This patch adds in a couple more properties related to call instructions
and the CFG within the function that should expose a little bit more
about the characteristics of the function.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D158681
|
|
This patch adds operand type counts to the detailed function properties
analysis. This is intended to enable more interesting and detailed
comparisons across different languages on specific metrics (like usage
of inline assembly or global values).
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D158018
|
|
This patch adds more detailed function properties gated behind a command
line flag for use primarily in experimentation and gathering statistics
on the functions in a module or project. The runtime cost should be
minimal as the computation is only done when the flag is set. There will
be a slight memory overhead when the ML inliner is enabled, but it
should be fairly small at a handful of bytes per function.
This is an adapted form of https://reviews.llvm.org/D109661.
Reviewed By: mtrofin
Differential Revision: https://reviews.llvm.org/D157358
|
|
Avoids relying on `assert` for some of the validation.
Differential Revision: https://reviews.llvm.org/D150827
|
|
Generalized support for subgraphs that get rendered unreachable, for
both `call` and `invoke` cases.
Differential Revision: https://reviews.llvm.org/D127921
|
|
There could be successors that were reached before but now are only
reachable from elsewhere in the CFG.
Suppose the following diamond CFG (lines are arrows pointing down):
A
/ \
B C
\ /
D
There's a call site in C that is inlined. Upon doing that, it turns out
it expands to:
call void @llvm.trap()
unreachable
D isn't reachable from C anymore, but we did discount it when we set up
FunctionPropertiesUpdater, so we need to re-include it here.
The patch also updates loop accounting to use LoopInfo rather than
traverse BBs.
Differential Revision: https://reviews.llvm.org/D127353
|
|
The update depends on LoopInfo, so we need that refreshed first, not
after.
Differential Revision: https://reviews.llvm.org/D127467
|
|
If the callsite is in a single BB loop, we need to exclude the BB from
the successor set (in which it'd be a member), because that set forms a
boundary at which we stop traversing the CFG, when re-ingesting BBs
after inlining; but after inlining, the callsite BB's new successors
should be visited.
Reviewed By: kazu
Differential Revision: https://reviews.llvm.org/D127178
|
|
Re-computing FunctionPropertiesInfo after each inlining may be very time
consuming: in certain cases, e.g. large caller with lots of callsites,
and when the overall IR doesn't increase (thus not tripping a size bloat
threshold).
This patch addresses this by incrementally updating
FunctionPropertiesInfo.
Differential Revision: https://reviews.llvm.org/D125841
|
|
The goal in 75881d8b023e was just modifying what `Result` is, didn't
need to also modify ::run.
|
|
The result is a data bag, this makes sure it's signaled to a user that
the data can't be mutated when, for example, doing something like:
auto &R = FAM.getResult<FunctionPropertiesAnalysis>(F)
...
R.Uses++
|
|
Number of lines output by preprocessor:
before: 1065940348
after: 1065307662
Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D120659
|
|
This patch eliminates pesky "No newline at end of file" messages from
git diff.
|
|
level loops.
|
|
Added LoadInstCount, StoreInstCount, MaxLoopDepth, LoopCount
Reviewed By: jdoerfert, mtrofin
Differential Revision: https://reviews.llvm.org/D82283
|
|
A printer pass and a lit test case was added.
Reviewed By: mtrofin
Differential Revision: https://reviews.llvm.org/D82523
|
|
this separates `analyze` logic from `FunctionPropertiesAnalysis`
Reviewed By: mtrofin
Differential Revision: https://reviews.llvm.org/D82521
|
|
(This reverts commit a5e0194709c40212694370e0ea789a1ca14548b5, and
corrects author).
Rename the pass to be able to extend it to function properties other than inliner features.
Reviewed By: mtrofin
Differential Revision: https://reviews.llvm.org/D82044
|
|
This reverts commit 44a6bda19b40f2dfcbe92fc3d58bb6276c71ef78. I forgot
to correctly attibute it to tarinduj. Fixing and resubmitting.
|
|
Rename the pass to be able to extend it to function properties other than inliner features.
Reviewed By: mtrofin
Differential Revision: https://reviews.llvm.org/D82044
|
