Cleanup includes: Transforms/IPO

Preprocessor output diff: -238205 lines
Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.ll

Cleanup includes: Transforms/IPO

Preprocessor output diff: -238205 lines
Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D122183

show more ...

[AlwaysInliner] Emit inline remark only when successful

Failures in `InlineFunction()` are caught after D121722, but `emitInlinedIntoBasedOnCost()` should only be called when inlining is successful.

[AlwaysInliner] Emit inline remark only when successful

Failures in `InlineFunction()` are caught after D121722, but `emitInlinedIntoBasedOnCost()` should only be called when inlining is successful. This also removes an unnecessary call to `shouldInline()` which always returned `InlineCost::getAlways()`.

Reviewed By: kyulee, nikic

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

show more ...

[AlwaysInliner] Check inliner errors even without assserts

When we build clang without asserts we should still check the result of
`InlineFunction()` to be sure there wasn't an error. Otherwise we c

[AlwaysInliner] Check inliner errors even without assserts

When we build clang without asserts we should still check the result of
`InlineFunction()` to be sure there wasn't an error. Otherwise we could
incorrectly merge attributes in the next line.

This also removes a redundent call to `getCaller()`.

Reviewed By: nikic

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

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

[AlwaysInliner] Check for callsite noinline attribute simplified

[AlwaysInliner] Respect noinline call site attribute

```
always_inline foo() { }

bar () {

noinline foo();
}
```

We should prefer call site attribute over attribute on decl. This is fix for Always

[AlwaysInliner] Respect noinline call site attribute

```
always_inline foo() { }

bar () {

noinline foo();
}
```

We should prefer call site attribute over attribute on decl. This is fix for AlwaysInliner, similar fix is needed for normal Inliner (follow up).

Related to https://reviews.llvm.org/D119061

Reviewed By: aeubanks

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

show more ...

Reland "[AlwaysInliner] Enable call site inlining to make flatten attribute working again (#53360)"

Revert "[AlwaysInliner] Enable call site inlining to make flatten attribute working again (#53360)"

This reverts commit ceec4383681c42bfd3d06a6913ce7554bea160b0. Clang tests fail.

[AlwaysInliner] Enable call site inlining to make flatten attribute working again (#53360)

Problem: Migration to new PM broke flatten attribute.

This is one use case why LLVM should support inlinin

[AlwaysInliner] Enable call site inlining to make flatten attribute working again (#53360)

Problem: Migration to new PM broke flatten attribute.

This is one use case why LLVM should support inlining call-site with alwaysinline. The flatten attribute is nowdays broken, so we should either land patch like this one or remove everything related to flatten attribute from Clang.

Second use case is something like "per call site inlining intrinsics" to control inlining even more; mentioned in
https://lists.llvm.org/pipermail/cfe-dev/2018-September/059232.html

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

Reviewed By: aeubanks

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

show more ...

[ModuleUtils] Remove dead arg from filterDeadComdatFunctions() (NFC)

The module argument is no longer used.

[AlwaysInliner] Invalidate analyses when we delete functions

Fixes PR52292.

Reviewed By: asbirlea

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

[inliner] Mandatory inlining decisions produce remarks

This also removes the need to disable the mandatory inlining phase in
tests.

In a departure from the previous remark, we don't output a 'cost'

[inliner] Mandatory inlining decisions produce remarks

This also removes the need to disable the mandatory inlining phase in
tests.

In a departure from the previous remark, we don't output a 'cost' in
this case, because there's no such thing. We just report that inlining
happened because of the attribute.

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

show more ...

[coroutine] should disable inline before calling coro split

This is a rework of D85812, which didn't land.
When callee coroutine function is inlined into caller coroutine function before coro-split

[coroutine] should disable inline before calling coro split

This is a rework of D85812, which didn't land.
When callee coroutine function is inlined into caller coroutine function before coro-split pass, llvm will emits "coroutine should have exactly one defining @llvm.coro.begin". It seems that coro-early pass can not handle this quiet well.
So we believe that unsplited coroutine function should not be inlined.
This patch fix such issue by not inlining function if it has attribute "coroutine.presplit" (it means the function has not been splited) to fix this issue
test plan: check-llvm, check-clang

In D85812, there was suggestions on moving the macros to Attributes.td to avoid circular header dependency issue.
I believe it's not worth doing just to be able to use one constant string in one place.
Today, there are already 3 possible attribute values for "coroutine.presplit": https://github.com/llvm/llvm-project/blob/c6543cc6b8f107b58e7205d8fc64865a508bacba/llvm/lib/Transforms/Coroutines/CoroInternal.h#L40-L42
If we move them into Attributes.td, we would be adding 3 new attributes to EnumAttr, just to support this, which I think is an overkill.

Instead, I think the best way to do this is to add an API in Function class that checks whether this function is a coroutine, by checking the attribute by name directly.

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

show more ...

[AlwaysInliner] Call mergeAttributesForInlining after inlining

Like inlineCallIfPossible and InlinerPass, after inlining mergeAttributesForInlining
should be called to merge callee's attributes to c

[AlwaysInliner] Call mergeAttributesForInlining after inlining

Like inlineCallIfPossible and InlinerPass, after inlining mergeAttributesForInlining
should be called to merge callee's attributes to caller. But it is not called in
AlwaysInliner, causes caller's attributes inconsistent with inlined code.

Attached test case demonstrates that attribute "min-legal-vector-width"="512" is
not merged into caller without this patch, and it causes failure in SelectionDAG
when lowering the inlined AVX512 intrinsic.

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

show more ...

Reland [AlwaysInliner] Pass callee AAResults to InlineFunction()

Test copied from noalias-calls.ll with small changes.

Reviewed By: asbirlea

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

Revert "[AlwaysInliner] Pass callee AAResults to InlineFunction()"

This reverts commit 504fbec7a61cdfbb5f6e1b25cf14afe5195ccaf6.

Test failure.

[AlwaysInliner] Pass callee AAResults to InlineFunction()

Test copied from noalias-calls.ll with small changes.

Reviewed By: asbirlea

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

Reland [AlwaysInliner] Update BFI when inlining

Reviewed By: davidxl

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

Revert "[AlwaysInliner] Update BFI when inlining"

This reverts commit b1bf24667fc3ec5dc4b541148d0d722ffa28a6df.

[AlwaysInliner] Update BFI when inlining

Reviewed By: davidxl

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

[AlwaysInliner] Emit optimization remarks

To match the normal inliner in preparation for https://reviews.llvm.org/D86988.

Also change a FIXME to an assert.

Reviewed By: davidxl

Differential Revis

[AlwaysInliner] Emit optimization remarks

To match the normal inliner in preparation for https://reviews.llvm.org/D86988.

Also change a FIXME to an assert.

Reviewed By: davidxl

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

show more ...

Revert D85812 "[coroutine] should disable inline before calling coro split"

This reverts commit 2e43acfed89b1903de473f682c65878bdebc395a.

LLVMCoroutines (the library which contains Coroutines.h) de

Revert D85812 "[coroutine] should disable inline before calling coro split"

This reverts commit 2e43acfed89b1903de473f682c65878bdebc395a.

LLVMCoroutines (the library which contains Coroutines.h) depends on LLVMipo (the
library which contains SampleProfile.cpp). It is inappropriate for
SampleProfile.cpp to depent on Coroutines.h (circular dependency).

The test inverted dependencies as well:
llvm/test/Transforms/Coroutines/coro-inline.ll uses -sample-profile.

show more ...

[coroutine] should disable inline before calling coro split
summary:
When callee coroutine function is inlined into caller coroutine
function before coro-split pass, llvm will emits "coroutine should

[coroutine] should disable inline before calling coro split
summary:
When callee coroutine function is inlined into caller coroutine
function before coro-split pass, llvm will emits "coroutine should
have exactly one defining @llvm.coro.begin". It seems that coro-early
pass can not handle this quiet well.
So we believe that unsplited coroutine function should not be inlined.
This patch fix such issue by not inlining function if it has attribute
"coroutine.presplit" (it means the function has not been splited) to
fix this issue

TestPlan: check-llvm

Reviewed By: wenlei

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

show more ...

Revert "Revert "[llvm][NFC] Cleanup uses of std::function in Inlining-related APIs""

This reverts commit 454de99a6fec705e76ed7743bf538f7a77296f59.

The problem was that one of the ctor arguments of

Revert "Revert "[llvm][NFC] Cleanup uses of std::function in Inlining-related APIs""

This reverts commit 454de99a6fec705e76ed7743bf538f7a77296f59.

The problem was that one of the ctor arguments of CallAnalyzer was left
to be const std::function<>&. A function_ref was passed for it, and then
the ctor stored the value in a function_ref field. So a std::function<>
would be created as a temporary, and not survive past the ctor
invocation, while the field would.

Tested locally by following https://github.com/google/sanitizers/wiki/SanitizerBotReproduceBuild

Original Differential Revision: https://reviews.llvm.org/D79917

show more ...

Revert "[llvm][NFC] Cleanup uses of std::function in Inlining-related APIs"

This reverts commit 767db5be67cab5aa04d81227725765cad9620611.