Add missing include under EXPENSIVE_CHECKS

Cleanup includes: DebugInfo & CodeGen

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

Revert "Add missing include under EXPENSIVE_CHECK"

This reverts commit eeaca53df7a030862bd1160950a6264aeb605cc6.

It's a duplicate of
https://reviews.llvm.org/rG50874a188b94a25827963956887b878d37015

Revert "Add missing include under EXPENSIVE_CHECK"

This reverts commit eeaca53df7a030862bd1160950a6264aeb605cc6.

It's a duplicate of
https://reviews.llvm.org/rG50874a188b94a25827963956887b878d3701509a

show more ...

Add missing include under EXPENSIVE_CHECK

This is a followup to 344f8ec3048b6eeef94569800acb012f794ad372

It should fix
https://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-expensive/21961/con

Add missing include under EXPENSIVE_CHECK

This is a followup to 344f8ec3048b6eeef94569800acb012f794ad372

It should fix
https://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-expensive/21961/console

show more ...

Fix -DLLVM_ENABLE_EXPENSIVE_CHECKS=on build after D120659

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

[Inliner] Don't removeDeadConstantUsers() when checking if a function is dead

If a function has many uses, this can take a good chunk of compile times.

Reviewed By: nikic

Differential Revision: ht

[Inliner] Don't removeDeadConstantUsers() when checking if a function is dead

If a function has many uses, this can take a good chunk of compile times.

Reviewed By: nikic

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

show more ...

[NFC][LazyCallGraph] Remove check in removeDeadFunction() if graph is empty

If we're in removeDeadFunction(), we should have already constructed the call graph.

Differential Revision: https://revie

[NFC][LazyCallGraph] Remove check in removeDeadFunction() if graph is empty

If we're in removeDeadFunction(), we should have already constructed the call graph.

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

show more ...

[LazyCallGraph] Ignore empty RefSCCs rather than shift RefSCCs when removing dead functions

This is in preparation for D115545 which attempts to delete discardable functions if they are unused. With

[LazyCallGraph] Ignore empty RefSCCs rather than shift RefSCCs when removing dead functions

This is in preparation for D115545 which attempts to delete discardable functions if they are unused. With that change, shifting RefSCCs becomes noticeable in compile time. This change makes the LCG update negligible again.

Reviewed By: nikic

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

show more ...

[LazyCallGraph] Skip blockaddresses

blockaddresses do not participate in the call graph since the only
instructions that use them must all return to someplace within the
current function. And passes

[LazyCallGraph] Skip blockaddresses

blockaddresses do not participate in the call graph since the only
instructions that use them must all return to someplace within the
current function. And passes cannot retrieve a function address from a
blockaddress.

This was suggested by efriedma in D58260.

Fixes PR50881.

Reviewed By: nickdesaulniers

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

show more ...

[NFC] De-template LazyCallGraph::visitReferences() and move into .cpp file

This makes changing it and recompiling it much faster.

[LCG] Don't skip invalidation of LazyCallGraph if CFG analyses are preserved

The CFG being changed and the overall call graph are not related, we can introduce/remove calls without changing the CFG.

[LCG] Don't skip invalidation of LazyCallGraph if CFG analyses are preserved

The CFG being changed and the overall call graph are not related, we can introduce/remove calls without changing the CFG.

Resolves one of the issues in PR51946.

Reviewed By: asbirlea

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

show more ...

Allow building for release with EXPENSIVE_CHECKS

D97225 moved LazyCallGraph verify() calls behind EXPENSIVE_CHECKS,
but verity() is defined for debug builds only so this had the unintended
effect of

Allow building for release with EXPENSIVE_CHECKS

D97225 moved LazyCallGraph verify() calls behind EXPENSIVE_CHECKS,
but verity() is defined for debug builds only so this had the unintended
effect of breaking release builds with EXPENSIVE_CHECKS.

Fix by enabling verify() for both debug and EXPENSIVE_CHECKS.

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

show more ...

Only verify LazyCallGraph under expensive checks

These verify calls are causing a lot of slowdown on some files, up to 8x.
The LazyCallGraph infra has been tested a lot over the years, so I'm fairly

Only verify LazyCallGraph under expensive checks

These verify calls are causing a lot of slowdown on some files, up to 8x.
The LazyCallGraph infra has been tested a lot over the years, so I'm fairly confident that we don't always need to run the verifys.

These verifies took >90% of total time in one of the compilations I looked at.

Reviewed By: thakis

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

show more ...

[llvm] Use llvm::drop_begin (NFC)

Fix non-assert builds after D93828

[CGSCC][Coroutine][NewPM] Properly support function splitting/outlining

Previously when trying to support CoroSplit's function splitting, we
added in a hack that simply added the new function's node

[CGSCC][Coroutine][NewPM] Properly support function splitting/outlining

Previously when trying to support CoroSplit's function splitting, we
added in a hack that simply added the new function's node into the
original function's SCC (https://reviews.llvm.org/D87798). This is
incorrect since it might be in its own SCC.

Now, more similar to the previous design, we have callers explicitly
notify the LazyCallGraph that a function has been split out from another
one.

In order to properly support CoroSplit, there are two ways functions can
be split out.

One is the normal expected "outlining" of one function into a new one.
The new function may only contain references to other functions that the
original did. The original function must reference the new function. The
new function may reference the original function, which can result in
the new function being in the same SCC as the original function. The
weird case is when the original function indirectly references the new
function, but the new function directly calls the original function,
resulting in the new SCC being a parent of the original function's SCC.
This form of function splitting works with CoroSplit's Switch ABI.

The second way of splitting is more specific to CoroSplit. CoroSplit's
Retcon and Async ABIs split the original function into multiple
functions that all reference each other and are referenced by the
original function. In order to keep the LazyCallGraph in a valid state,
all new functions must be processed together, else some nodes won't be
populated. To keep things simple, this only supports the case where all
new edges are ref edges, and every new function references every other
new function. There can be a reference back from any new function to the
original function, putting all functions in the same RefSCC.

This also adds asserts that all nodes in a (Ref)SCC can reach all other
nodes to prevent future incorrect hacks.

The original hacks in https://reviews.llvm.org/D87798 are no longer
necessary since all new functions should have been registered before
calling updateCGAndAnalysisManagerForPass.

This fixes all coroutine tests when opt's -enable-new-pm is true by
default. This also fixes PR48190, which was likely due to the previous
hack breaking SCC invariants.

Reviewed By: rnk

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

show more ...

Remove RefSCC::handleTrivialEdgeInsertion

This function no longer does anything useful. It probably did something originally but latter changes removed them and didn't clean up this function.
The ch

Remove RefSCC::handleTrivialEdgeInsertion

This function no longer does anything useful. It probably did something originally but latter changes removed them and didn't clean up this function.
The checks are already done in the callers as well.

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

show more ...

[LazyCallGraph] Build SCCs of the reference graph in order

```
// The legacy PM CGPassManager discovers SCCs this way:
for function in the source order
tarjanSCC(function)

// While the new PM CGS

[LazyCallGraph] Build SCCs of the reference graph in order

```
// The legacy PM CGPassManager discovers SCCs this way:
for function in the source order
tarjanSCC(function)

// While the new PM CGSCCPassManager does:
for function in the reversed source order [1]
discover a reference graph SCC
build call graph SCCs inside the reference graph SCC
```

In the common cases, reference graph ~= call graph, the new PM order is
undesired because for `a | b | c` (3 independent functions), the new PM will
process them in the reversed order: c, b, a. If `a <-> b <-> c`, we can see
that `-print-after-all` will report the sole SCC as `scc: (c, b, a)`.

This patch corrects the iteration order. The discovered SCC order will match
the legacy PM in the common cases.

For some tests (`Transforms/Inline/cgscc-*.ll` and
`unittests/Analysis/CGSCCPassManagerTest.cpp`), the behaviors are dependent on
the SCC discovery order and there are too many check lines for the particular
order. This patch simply reverses the function order to avoid changing too many
check lines.

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

show more ...

[NewPM][CGSCC] Handle newly added functions in updateCGAndAnalysisManagerForPass

This seems to fit the CGSCC updates model better than calling
addNewFunctionInto{Ref,}SCC() on newly created/outlined

[NewPM][CGSCC] Handle newly added functions in updateCGAndAnalysisManagerForPass

This seems to fit the CGSCC updates model better than calling
addNewFunctionInto{Ref,}SCC() on newly created/outlined functions.
Now addNewFunctionInto{Ref,}SCC() are no longer necessary.

However, this doesn't work on newly outlined functions that aren't
referenced by the original function. e.g. if a() was outlined into b()
and c(), but c() is only referenced by b() and not by a(), this will
trigger an assert.

This also fixes an issue I was seeing with newly created functions not
having passes run on them.

Ran check-llvm with expensive checks.

Reviewed By: asbirlea

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

show more ...

[CGSCC][NewPM] Fix adding mutually recursive new functions

When adding a new function via addNewFunctionIntoRefSCC(), it creates a
new node and immediately populates the edges. Since populateSlow()

[CGSCC][NewPM] Fix adding mutually recursive new functions

When adding a new function via addNewFunctionIntoRefSCC(), it creates a
new node and immediately populates the edges. Since populateSlow() calls
G->get() on all referenced functions, it will create a node (but not
populate it) for functions that haven't yet been added. If we add two
mutually recursive functions, the assert that the node should never have
been created will fire when the second function is added. So here we
remove that assert since the node may have already been created (but not
yet populated).

createNode() is only called from addNewFunctionInto{,Ref}SCC().

https://bugs.llvm.org/show_bug.cgi?id=47502

Reviewed By: jdoerfert

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

show more ...

[llvm][NFC][CallSite] Remove Implementation uses of CallSite

Reviewers: dblaikie, davidxl, craig.topper

Subscribers: arsenm, dschuff, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, hiradity

[llvm][NFC][CallSite] Remove Implementation uses of CallSite

Reviewers: dblaikie, davidxl, craig.topper

Subscribers: arsenm, dschuff, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, hiraditya, aheejin, kbarton, kerbowa, llvm-commits

Tags: #llvm

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

show more ...

[LazyCallGraph] Fix ambiguous index value

After having committed https://reviews.llvm.org/D72226, 2 buildbots
running GCC 5.4.0 began failing. The cause was the order in which those
compilers evalua

[LazyCallGraph] Fix ambiguous index value

After having committed https://reviews.llvm.org/D72226, 2 buildbots
running GCC 5.4.0 began failing. The cause was the order in which those
compilers evaluated the left- and right-hand sides of the expression
`RC.SCCIndices[C] = RC.SCCIndices.size();`. This commit splits the
expression into multiple statements to avoid ambiguity, and adds a test
case that exercises the code that caused the test failures on those
older compilers (which was originally included in the reviewed patch,
https://reviews.llvm.org/D72226).

show more ...

Re-land "Add LazyCallGraph API to add function to RefSCC"

This re-commits https://reviews.llvm.org/D70927, which I reverted in
https://reviews.llvm.org/rG28213680b2a7d1fdeea16aa3f3a368879472c72a due

Re-land "Add LazyCallGraph API to add function to RefSCC"

This re-commits https://reviews.llvm.org/D70927, which I reverted in
https://reviews.llvm.org/rG28213680b2a7d1fdeea16aa3f3a368879472c72a due
to a buildbot error:
http://lab.llvm.org:8011/builders/clang-cmake-x86_64-avx2-linux/builds/13251

I no longer include a test case that appears to crash when built with the
buildbot's compiler, GCC 5.4.0.

show more ...

Revert "Add LazyCallGraph API to add function to RefSCC"

This reverts commit https://reviews.llvm.org/rG449a13509190b1c57e5fcf5cd7e8f0f647f564b4,
due to buildbot failures such as
http://lab.llvm.org

Revert "Add LazyCallGraph API to add function to RefSCC"

This reverts commit https://reviews.llvm.org/rG449a13509190b1c57e5fcf5cd7e8f0f647f564b4,
due to buildbot failures such as
http://lab.llvm.org:8011/builders/clang-cmake-x86_64-avx2-linux/builds/13251.

show more ...