[NFC] Rename the `Nr` abbreviation to `Num` (#107151)

It's more clear. (This isn't exhaustive).

Reapply "[nfc][mlgo] Incrementally update DominatorTreeAnalysis in FunctionPropertiesAnalysis (#104867) (#106309)

Reverts c992690179eb5de6efe47d5c8f3a23f2302723f2.

The problem is that if there is

Reapply "[nfc][mlgo] Incrementally update DominatorTreeAnalysis in 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.

show more ...

Revert "[nfc][mlgo] Incrementally update DominatorTreeAnalysis in FunctionPropertiesAnalysis (#104867)"

This seems to cause asserts in our builds:

llvm/include/llvm/Support/GenericDomTreeConstruc

Revert "[nfc][mlgo] Incrementally update DominatorTreeAnalysis in 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.

show more ...

Fix bot failures after PR #104867

An assert was left over after addressing feedback. In the process of
fixing, realized the way I addressed the feedback was also incomplete.

[nfc][mlgo] Incrementally update DominatorTreeAnalysis in FunctionPropertiesAnalysis (#104867)

We need the dominator tree analysis for loop info analysis, which we need to get features like most nes

[nfc][mlgo] Incrementally update DominatorTreeAnalysis in 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.

show more ...

[llvm] format and terminate namespaces with closing comment (#94917)

Namespaces are terminated with a closing comment in the majority of the
codebase so do the same here for consistency. Also forma

[llvm] format and terminate namespaces with closing comment (#94917)

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.

show more ...

Move global namespace cl::opt inside llvm:: or internalize them

[FunctionPropertiesAnalysis] Add CFG and call properties

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

[FunctionPropertiesAnalysis] Add CFG and call properties

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

show more ...

[FunctionPropertiesAnalysis] Add operand type counts

This patch adds operand type counts to the detailed function properties
analysis. This is intended to enable more interesting and detailed
compar

[FunctionPropertiesAnalysis] Add operand type counts

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

show more ...

[FunctionPropertiesAnalysis] Add detailed analysis

This patch adds more detailed function properties gated behind a command
line flag for use primarily in experimentation and gathering statistics
on

[FunctionPropertiesAnalysis] Add detailed analysis

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

show more ...

[NFC] Surface the validation of FunctionPropertiesAnalysis

Avoids relying on `assert` for some of the validation.

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

[FunctionPropertiesAnalysis] Generalize support for unreachable

Generalized support for subgraphs that get rendered unreachable, for
both `call` and `invoke` cases.

Differential Revision: https://r

[FunctionPropertiesAnalysis] Generalize support for unreachable

Generalized support for subgraphs that get rendered unreachable, for
both `call` and `invoke` cases.

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

show more ...

FunctionPropertiesAnalysis: handle callsite BBs that lose edges

There could be successors that were reached before but now are only
reachable from elsewhere in the CFG.

Suppose the following diamon

FunctionPropertiesAnalysis: handle callsite BBs that lose edges

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

show more ...

[mlgo] Update FunctionPropertyCache after invalidating analyses

The update depends on LoopInfo, so we need that refreshed first, not
after.

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

Fix FunctionPropertiesAnalysis updating callsite in 1-BB loop

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 f

Fix FunctionPropertiesAnalysis updating callsite in 1-BB loop

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

show more ...

[mlgo] Incrementally update FunctionPropertiesInfo during inlining

Re-computing FunctionPropertiesInfo after each inlining may be very time
consuming: in certain cases, e.g. large caller with lots o

[mlgo] Incrementally update FunctionPropertiesInfo during inlining

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

show more ...

[NFC] remove const from FunctionPropertiesAnalysis::run, keep on Result

The goal in 75881d8b023e was just modifying what `Result` is, didn't
need to also modify ::run.

[NFC] const-ed the return type of FunctionPropertiesAnalysis

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:

[NFC] const-ed the return type of FunctionPropertiesAnalysis

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++

show more ...

Cleanup includes: LLVMAnalysis

Number of lines output by preprocessor:
before: 1065940348
after: 1065307662

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Diff

Cleanup includes: LLVMAnalysis

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

show more ...

[llvm] Ensure newlines at the end of files (NFC)

This patch eliminates pesky "No newline at end of file" messages from
git diff.

Use llvm::size rather than an empty loop to get the number of top
level loops.

Add new function properties to FunctionPropertiesAnalysis

Added LoadInstCount, StoreInstCount, MaxLoopDepth, LoopCount

Reviewed By: jdoerfert, mtrofin

Differential Revision: https://reviews.llvm

Add new function properties to FunctionPropertiesAnalysis

Added LoadInstCount, StoreInstCount, MaxLoopDepth, LoopCount

Reviewed By: jdoerfert, mtrofin

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

show more ...

Add a Printer to the FunctionPropertiesAnalysis

A printer pass and a lit test case was added.

Reviewed By: mtrofin

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

Refactor FunctionPropertiesAnalysis

this separates `analyze` logic from `FunctionPropertiesAnalysis`

Reviewed By: mtrofin

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

Reapply "Rename InlineFeatureAnalysis to FunctionPropertiesAnalysis"

(This reverts commit a5e0194709c40212694370e0ea789a1ca14548b5, and
corrects author).

Rename the pass to be able to extend it to

Reapply "Rename InlineFeatureAnalysis to FunctionPropertiesAnalysis"

(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

show more ...