[Scalar] Remove unused includes (NFC) (#114645)

Identified with misc-include-cleaner.

[llvm] Support llvm::Any across shared libraries on windows (#108051)

This is part of the effort to support for enabling plugins on windows by
adding better support for building llvm as a DLL. The

[llvm] Support llvm::Any across shared libraries on windows (#108051)

This is part of the effort to support for enabling plugins on windows by
adding better support for building llvm as a DLL. The export macros used
here were added in #96630

Since shared library symbols aren't deduplicated across multiple
libraries on windows like Linux we have to manually explicitly import
and export `Any::TypeId` template instantiations for the uses of
`llvm::Any` in the LLVM codebase to support LLVM Windows shared library
builds.
This change ensures that external code, including LLVM's own tests, can
use PassManager callbacks when LLVM is built as a DLL.

I also removed the only use of llvm::Any for LoopNest that only existed
in debug code and there also doesn't seem to be any code creating
`Any<LoopNest>`

show more ...

Fix LLVM_ENABLE_ABI_BREAKING_CHECKS macro check: use #if instead of #ifdef (#110938)

This macros is always defined: either 0 or 1. The correct pattern is to
use #if.

Re-apply #110185 with more f

Fix LLVM_ENABLE_ABI_BREAKING_CHECKS macro check: use #if instead of #ifdef (#110938)

This macros is always defined: either 0 or 1. The correct pattern is to
use #if.

Re-apply #110185 with more fixes for debug build with the ABI breaking
checks disabled.

show more ...

[LPM] Set gen_crash_diag=false for non-MSSA pass in MSSA pipeline

When a loop pass that does not preserve MSSA is run as part of a
loop-mssa pipeline, this is user error and we should not ask for
a

[LPM] Set gen_crash_diag=false for non-MSSA pass in MSSA pipeline

When a loop pass that does not preserve MSSA is run as part of a
loop-mssa pipeline, this is user error and we should not ask for
a bug report.

Fixes https://github.com/llvm/llvm-project/issues/73554.

show more ...

[llvm] Use llvm::any_cast instead of any_cast (NFC) (#65565)

This patch replaces any_cast with llvm::any_cast. This in turn allows us
to gracefully switch to std::any in future by forwarding llvm::

[llvm] Use llvm::any_cast instead of any_cast (NFC) (#65565)

This patch replaces any_cast with llvm::any_cast. This in turn allows us
to gracefully switch to std::any in future by forwarding llvm::Any and
llvm::any_cast to:

using Any = std::any;

template <class T> T *any_cast(Any *Value) {
return std::any_cast<T>(Value);
}

respectively.

Without this patch, it's ambiguous whether any_cast refers to
std::any_cast or llvm::any_cast.

As an added bonus, this patch makes it easier to mechanically replace
llvm::any_cast with std::any_cast without affecting other occurrences of
any_cast (e.g. in libcxx).

show more ...

[NFC] Use single quotes for single char output during `printPipline`

Reviewed By: arsenm

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

[llvm] Make llvm::Any similar to std::any

This facilitates replacing llvm::Any with std::any.
- Deprecate any_isa in favor of using any_cast(Any*) and checking for
nullptr because C++17 has no any

[llvm] Make llvm::Any similar to std::any

This facilitates replacing llvm::Any with std::any.
- Deprecate any_isa in favor of using any_cast(Any*) and checking for
nullptr because C++17 has no any_isa.
- Remove the assert from any_cast(Any*), so it returns nullptr if the
type is not correct. This aligns it with std::any_cast(any*).

Use any_cast(Any*) throughout LLVM instead of checks with any_isa.

This is the first part outlined in
https://discourse.llvm.org/t/rfc-switching-from-llvm-any-to-std-any/67176

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

show more ...

[Transforms/Scalar] llvm::Optional => std::optional

Revert "[llvm] Replace llvm::Any with std::any"

msvc fails to link when using any_cast. This seems to be fixed recently
only.

https://developercommunity.visualstudio.com/t/stdany-doesnt-link-when-e

Revert "[llvm] Replace llvm::Any with std::any"

msvc fails to link when using any_cast. This seems to be fixed recently
only.

https://developercommunity.visualstudio.com/t/stdany-doesnt-link-when-exceptions-are-disabled/376072

This reverts commit aeac2e4884a3ce62c920cd51806a9396da64d9f7.

show more ...

[llvm] Replace llvm::Any with std::any

llvm::Any had several bugs in the past, due to being sensitive to symbol
visibility. (See D101972 and D108943)

Even with these fixes applied, I still encounte

[llvm] Replace llvm::Any with std::any

llvm::Any had several bugs in the past, due to being sensitive to symbol
visibility. (See D101972 and D108943)

Even with these fixes applied, I still encounter the same issue on
Windows.

Similar to llvm::Optional going away in favor of std::optional, we can
use std::any from C++17.

Using std::any fixes the problem and puts the burden to do it correctly
on the standard library.

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

show more ...

[LoopPassManager] Ensure to construct loop nests with the outermost loop

This patch is to resolve the bug reported and discussed in
https://reviews.llvm.org/D124926#3718761 and https://reviews.llvm.

[LoopPassManager] Ensure to construct loop nests with the outermost loop

This patch is to resolve the bug reported and discussed in
https://reviews.llvm.org/D124926#3718761 and https://reviews.llvm.org/D124926#3719876.

The problem is that loop interchange is a loopnest pass under the new pass manager,
but the loop nest may not be constructed correctly by the loop pass manager after
running loop interchange and before running the next pass, which might cause problems
when it continues running the next pass.

The reason that the loop nest is constructed incorrectly is that the outermost
loop might have changed after interchange, and what was the original outermost
loop is not the current outermost loop anymore. Constructing the loop nest based
on the original outermost loop would generate an invalid loop nest.

The fix in this patch is that, in the loop pass manager before running each loopnest
pass, we re-cosntruct the loop nest based on the current outermost loop, if LPMUpdater
notifies the loop pass manager that the previous loop nest has been invalidated by passes
like loop interchange.

Reviewed By: aeubanks

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

show more ...

[Clang] Reimplement time tracing of NewPassManager by PassInstrumentation framework

The previous implementation of time tracing in NewPassManager is direct but messive.

The key codes are like the d

[Clang] Reimplement time tracing of NewPassManager by PassInstrumentation framework

The previous implementation of time tracing in NewPassManager is direct but messive.

The key codes are like the demo below:
```
/// Runs the function pass across every function in the module.
PreservedAnalyses run(LazyCallGraph::SCC &C, CGSCCAnalysisManager &AM,
LazyCallGraph &CG, CGSCCUpdateResult &UR) {
/// ...
PreservedAnalyses PassPA;
{
TimeTraceScope TimeScope(Pass.name());
PassPA = Pass.run(F, FAM);
}
/// ...
}
```

It can be bothered to judge where should we add the tracing codes by hands.

With the PassInstrumentation framework, we can easily add `Before/After` callback
functions to add time tracing codes.

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

show more ...

Revert "[LoopPassManager] Implement and use LoopNestAnalysis::run() instead of manually creating LoopNests"

This reverts commit 57fd8665516161c3d2dbe3f0ad8461552967692a.

Causes crashes, see comment

Revert "[LoopPassManager] Implement and use LoopNestAnalysis::run() instead of manually creating LoopNests"

This reverts commit 57fd8665516161c3d2dbe3f0ad8461552967692a.

Causes crashes, see comments in D132581.

show more ...

[LoopPassManager] Implement and use LoopNestAnalysis::run() instead of manually creating LoopNests

The current code is basically just emulating what the analysis manager does.

Reviewed By: asbirlea

[LoopPassManager] Implement and use LoopNestAnalysis::run() instead of manually creating LoopNests

The current code is basically just emulating what the analysis manager does.

Reviewed By: asbirlea

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

show more ...

Revert "[PassManager] Add pretty stack entries before P->run() call."

This reverts commit 128745cc2681c284bc6d0150a319673a6d6e8424.

This increased compile-time unnecessarily. Revert this change and

Revert "[PassManager] Add pretty stack entries before P->run() call."

This reverts commit 128745cc2681c284bc6d0150a319673a6d6e8424.

This increased compile-time unnecessarily. Revert this change and follow
ups 2c7afadb4789 & add0c5856d5f.

http://llvm-compile-time-tracker.com/compare.php?from=338dfcd60f843082bb589b287d890dbd9394eb82&to=128745cc2681c284bc6d0150a319673a6d6e8424&stat=instructions

show more ...

[PassManager] Add pretty stack entries before P->run() call.

This patch adds PrettyStackEntries before running passes. The entries
include the pass name and the IR unit the pass runs on.

The inform

[PassManager] Add pretty stack entries before P->run() call.

This patch adds PrettyStackEntries before running passes. The entries
include the pass name and the IR unit the pass runs on.

The information is used the print additional information when a pass
crashes, including the name and a reference to the IR unit on which it
crashed. This is similar to the behavior of the legacy pass manager.

The improved stack trace now includes:

Stack dump:
0. Program arguments: bin/opt -loop-vectorize -force-vector-width=4 crash.ll
1. Running pass 'ModuleToFunctionPassAdaptor' on module 'crash.ll'
2. Running pass 'LoopVectorizePass' on function '@a'

Reviewed By: aeubanks

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

show more ...

[SCEV] Enable verification in LoopPM

Currently, we hardly ever actually run SCEV verification, even in
tests with -verify-scev. This is because the NewPM LPM does not
verify SCEV. The reason for thi

[SCEV] Enable verification in LoopPM

Currently, we hardly ever actually run SCEV verification, even in
tests with -verify-scev. This is because the NewPM LPM does not
verify SCEV. The reason for this is that SCEV verification can
actually change the result of subsequent SCEV queries, which means
that you see different transformations depending on whether
verification is enabled or not.

To allow verification in the LPM, this limits verification to
BECounts that have actually been cached. It will not calculate
new BECounts.

BackedgeTakenInfo::getExact() is still not entirely readonly,
it still calls getUMinFromMismatchedTypes(). But I hope that this
is not problematic in the same way. (This could be avoided by
performing the umin in the other SCEV instance, but this would
require duplicating some of the code.)

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

show more ...

Cleanup includes: Transform/Scalar

Estimated impact on preprocessor output line:
before: 1062981579
after: 1062494547

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

Cleanup includes: Transform/Scalar

Estimated impact on preprocessor output line:
before: 1062981579
after: 1062494547

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

show more ...

Cleanup includes: TransformsUtils

Estimation on the impact on preprocessor output:
before: 1065307662
after: 1064800684

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

Cleanup includes: TransformsUtils

Estimation on the impact on preprocessor output:
before: 1065307662
after: 1064800684

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

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

[NPM] Fix LoopNestPasses in -print-pipeline-passes

Fix printing of LoopNestPasses when using the opt pipeline printer
option -print-pipeline-passes.

Reviewed By: aeubanks

Differential Revision: ht

[NPM] Fix LoopNestPasses in -print-pipeline-passes

Fix printing of LoopNestPasses when using the opt pipeline printer
option -print-pipeline-passes.

Reviewed By: aeubanks

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

show more ...

[BPI] Keep BPI available in loop passes through LoopStandardAnalysisResults

This is analogous to D86156 (which preserves "lossy" BFI in loop
passes). Lossy means that the analysis preserved may not

[BPI] Keep BPI available in loop passes through LoopStandardAnalysisResults

This is analogous to D86156 (which preserves "lossy" BFI in loop
passes). Lossy means that the analysis preserved may not be up to date
with regards to new blocks that are added in loop passes, but BPI will
not contain stale pointers to basic blocks that are deleted by the loop
passes.

This is achieved through BasicBlockCallbackVH in BPI, which calls
eraseBlock that updates the data structures in BPI whenever a basic
block is deleted.

This patch does not have any changes in the upstream pipeline, since
none of the loop passes in the pipeline use BPI currently.
However, since BPI wasn't previously preserved in loop passes, the loop
predication pass was invoking BPI *on the entire
function* every time it ran in an LPM. This caused massive compile time
in our downstream LPM invocation which contained loop predication.

See updated test with an invocation of a loop-pipeline containing loop
predication and -debug-pass turned ON.

Reviewed-By: asbirlea, modimo
Differential Revision: https://reviews.llvm.org/D110438

show more ...

[NFC] Remove FIXMEs about calling LLVMContext::yield()

Nobody has complained about this, and the documentation for
LLVMContext::yield() states that LLVM is allowed to never call it.

Reviewed By: as

[NFC] Remove FIXMEs about calling LLVMContext::yield()

Nobody has complained about this, and the documentation for
LLVMContext::yield() states that LLVM is allowed to never call it.

Reviewed By: asbirlea

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

show more ...

[NPM] Added opt option -print-pipeline-passes.

Added opt option -print-pipeline-passes to print a -passes compatible
string describing the built pass pipeline.

As an example:
$ opt -enable-new-pm=1

[NPM] Added opt option -print-pipeline-passes.

Added opt option -print-pipeline-passes to print a -passes compatible
string describing the built pass pipeline.

As an example:
$ opt -enable-new-pm=1 -adce -licm -simplifycfg -o /dev/null /dev/null -print-pipeline-passes
verify,function(adce),function(loop-mssa(licm)),function(simplifycfg<bonus-inst-threshold=1;no-forward-switch-cond;no-switch-to-lookup;keep-loops;no-hoist-common-insts;no-sink-common-insts>),verify,BitcodeWriterPass

At the moment this is best-effort only and there are some known
limitations:
- Not all passes accepting parameters will print their parameters
(currently only implemented for simplifycfg).
- Some ClassName to pass-name mappings are not unique.
- Some ClassName to pass-name mappings are missing (e.g.
BitcodeWriterPass).

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

show more ...

Revert "[NPM] Added opt option -print-pipeline-passes."

This reverts commit c71869ed4c24b3d4d13e2f83ee2c0104013ca129.