<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/llvm/lib/Transforms/IPO/Inliner.cpp, branch users/nico/python-2</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/'/>
<entry>
<title>[MemProf] Emit remarks when hinting allocations not needing cloning (#141859)</title>
<updated>2025-05-28T23:44:44+00:00</updated>
<author>
<name>Teresa Johnson</name>
<email>tejohnson@google.com</email>
</author>
<published>2025-05-28T23:44:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=49d48c32e04742ebd05cbbd7dd544b1217b6d9d0'/>
<id>49d48c32e04742ebd05cbbd7dd544b1217b6d9d0</id>
<content type='text'>
The context disambiguation code already emits remarks when hinting
allocations (by adding hotness attributes) during cloning. However,
we did not yet emit hints when applying the hotness attributes during
building of the metadata (during matching and again after inlining).
Add remarks when we apply the hint attributes for these
non-context-sensitive allocations.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The context disambiguation code already emits remarks when hinting
allocations (by adding hotness attributes) during cloning. However,
we did not yet emit hints when applying the hotness attributes during
building of the metadata (during matching and again after inlining).
Add remarks when we apply the hint attributes for these
non-context-sensitive allocations.</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "[Analysis][EphemeralValuesAnalysis][NFCI] Remove EphemeralValuesCache class (#132454)"</title>
<updated>2025-03-22T17:13:39+00:00</updated>
<author>
<name>Vasileios Porpodas</name>
<email>vporpodas@google.com</email>
</author>
<published>2025-03-22T16:53:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=973ea045aa89febc533cea165e78686e976b3805'/>
<id>973ea045aa89febc533cea165e78686e976b3805</id>
<content type='text'>
This reverts commit 4adefcfb856aa304b7b0a9de1eec1814f3820e83.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 4adefcfb856aa304b7b0a9de1eec1814f3820e83.
</pre>
</div>
</content>
</entry>
<entry>
<title>[Analysis][EphemeralValuesAnalysis][NFCI] Remove EphemeralValuesCache class (#132454)</title>
<updated>2025-03-22T01:18:03+00:00</updated>
<author>
<name>vporpo</name>
<email>vporpodas@google.com</email>
</author>
<published>2025-03-22T01:18:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=4adefcfb856aa304b7b0a9de1eec1814f3820e83'/>
<id>4adefcfb856aa304b7b0a9de1eec1814f3820e83</id>
<content type='text'>
This is a follow-up to https://github.com/llvm/llvm-project/pull/130210.
The EphemeralValuesAnalysis pass used to return an EphemeralValuesCache
object which used to hold the ephemeral values and used to provide a
lazy collection of the ephemeral values, and an invalidation using the
`clear()` function.

This patch removes the EphemeralValuesCache class completely and instead
returns the SmallVector containing the ephemeral values.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is a follow-up to https://github.com/llvm/llvm-project/pull/130210.
The EphemeralValuesAnalysis pass used to return an EphemeralValuesCache
object which used to hold the ephemeral values and used to provide a
lazy collection of the ephemeral values, and an invalidation using the
`clear()` function.

This patch removes the EphemeralValuesCache class completely and instead
returns the SmallVector containing the ephemeral values.</pre>
</div>
</content>
</entry>
<entry>
<title>[Analysis][EphemeralValuesCache][InlineCost] Ephemeral values caching for the CallAnalyzer (#130210)</title>
<updated>2025-03-20T01:18:45+00:00</updated>
<author>
<name>vporpo</name>
<email>vporpodas@google.com</email>
</author>
<published>2025-03-20T01:18:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=08dda4dcbf6427e357830d9c7f7ac3b422fc75f6'/>
<id>08dda4dcbf6427e357830d9c7f7ac3b422fc75f6</id>
<content type='text'>
This patch does two things:

1. It implements an ephemeral values cache analysis pass that collects the ephemeral values of a function and caches them for fast lookups. The collection of the ephemeral values is done lazily when the user calls `EphemeralValuesCache::ephValues()`.

2. It adds caching of ephemeral values using the `EphemeralValuesCache` to speed up `CallAnalyzer::analyze()`. Without caching this can take a long time to run in cases where the function contains a large number of `@llvm.assume()` calls and a large number of callsites. The time is spent in `collectEphemeralvalues()`.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch does two things:

1. It implements an ephemeral values cache analysis pass that collects the ephemeral values of a function and caches them for fast lookups. The collection of the ephemeral values is done lazily when the user calls `EphemeralValuesCache::ephValues()`.

2. It adds caching of ephemeral values using the `EphemeralValuesCache` to speed up `CallAnalyzer::analyze()`. Without caching this can take a long time to run in cases where the function contains a large number of `@llvm.assume()` calls and a large number of callsites. The time is spent in `collectEphemeralvalues()`.</pre>
</div>
</content>
</entry>
<entry>
<title>[IPO] Remove unused includes (NFC) (#114716)</title>
<updated>2024-11-03T21:48:55+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2024-11-03T21:48:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=98ea1a81a28a6dd36941456c8ab4ce46f665f57a'/>
<id>98ea1a81a28a6dd36941456c8ab4ce46f665f57a</id>
<content type='text'>
Identified with misc-include-cleaner.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Identified with misc-include-cleaner.</pre>
</div>
</content>
</entry>
<entry>
<title>[Inliner] Pass updated SCC to InlineAdvisor::onPassExit() (#96553)</title>
<updated>2024-06-28T21:12:14+00:00</updated>
<author>
<name>Arthur Eubanks</name>
<email>aeubanks@google.com</email>
</author>
<published>2024-06-28T21:12:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=a8b722702db9bbf88f67a31c0c308865154576e2'/>
<id>a8b722702db9bbf88f67a31c0c308865154576e2</id>
<content type='text'>
InitialC may be logically invalid, although iterating through it doesn't
crash. Always use the updated SCC.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
InitialC may be logically invalid, although iterating through it doesn't
crash. Always use the updated SCC.</pre>
</div>
</content>
</entry>
<entry>
<title>[CGSCC] Fix compile time blowup with large RefSCCs (#94815)</title>
<updated>2024-06-11T16:50:13+00:00</updated>
<author>
<name>Arthur Eubanks</name>
<email>aeubanks@google.com</email>
</author>
<published>2024-06-11T16:50:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=71497cc7a4695d22fc5dfd64958744816c15a19e'/>
<id>71497cc7a4695d22fc5dfd64958744816c15a19e</id>
<content type='text'>
In some modules, e.g. Kotlin-generated IR, we end up with a huge RefSCC
and the call graph updates done as a result of the inliner take a long
time. This is due to RefSCC::removeInternalRefEdges() getting called
many times, each time removing one function from the RefSCC, but each
call to removeInternalRefEdges() is proportional to the size of the
RefSCC.

There are two places that call removeInternalRefEdges(), in
updateCGAndAnalysisManagerForPass() and
LazyCallGraph::removeDeadFunction().

1) Since LazyCallGraph can deal with spurious (edges that exist in the
graph but not in the IR) ref edges, we can simply not call
removeInternalRefEdges() in updateCGAndAnalysisManagerForPass().

2) LazyCallGraph::removeDeadFunction() still ends up taking the brunt of
compile time with the above change for the original reason. So instead
we batch all the dead function removals so we can call
removeInternalRefEdges() just once. This requires some changes to
callers of removeDeadFunction() to not actually erase the function from
the module, but defer it to when we batch delete dead functions at the
end of the CGSCC run, leaving the function body as "unreachable" in the
meantime. We still need to ensure that call edges are accurate. I had
also tried deleting dead functions after visiting a RefSCC, but deleting
them all at once at the end was simpler.

Many test changes are due to not performing unnecessary revisits of an
SCC (the CGSCC infrastructure deems ref edge refinements as unimportant
when it comes to revisiting SCCs, although that seems to not be
consistently true given these changes) because we don't remove some ref
edges. Specifically for devirt-invalidated.ll this seems to expose an
inlining order issue with the inliner. Probably unimportant for this
type of intentionally weird call graph.

Compile time:
https://llvm-compile-time-tracker.com/compare.php?from=6f2c61071c274a1b5e212e6ad4114641ec7c7fc3&amp;to=b08c90d05e290dd065755ea776ceaf1420680224&amp;stat=instructions:u</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In some modules, e.g. Kotlin-generated IR, we end up with a huge RefSCC
and the call graph updates done as a result of the inliner take a long
time. This is due to RefSCC::removeInternalRefEdges() getting called
many times, each time removing one function from the RefSCC, but each
call to removeInternalRefEdges() is proportional to the size of the
RefSCC.

There are two places that call removeInternalRefEdges(), in
updateCGAndAnalysisManagerForPass() and
LazyCallGraph::removeDeadFunction().

1) Since LazyCallGraph can deal with spurious (edges that exist in the
graph but not in the IR) ref edges, we can simply not call
removeInternalRefEdges() in updateCGAndAnalysisManagerForPass().

2) LazyCallGraph::removeDeadFunction() still ends up taking the brunt of
compile time with the above change for the original reason. So instead
we batch all the dead function removals so we can call
removeInternalRefEdges() just once. This requires some changes to
callers of removeDeadFunction() to not actually erase the function from
the module, but defer it to when we batch delete dead functions at the
end of the CGSCC run, leaving the function body as "unreachable" in the
meantime. We still need to ensure that call edges are accurate. I had
also tried deleting dead functions after visiting a RefSCC, but deleting
them all at once at the end was simpler.

Many test changes are due to not performing unnecessary revisits of an
SCC (the CGSCC infrastructure deems ref edge refinements as unimportant
when it comes to revisiting SCCs, although that seems to not be
consistently true given these changes) because we don't remove some ref
edges. Specifically for devirt-invalidated.ll this seems to expose an
inlining order issue with the inliner. Probably unimportant for this
type of intentionally weird call graph.

Compile time:
https://llvm-compile-time-tracker.com/compare.php?from=6f2c61071c274a1b5e212e6ad4114641ec7c7fc3&amp;to=b08c90d05e290dd065755ea776ceaf1420680224&amp;stat=instructions:u</pre>
</div>
</content>
</entry>
<entry>
<title>[llvm] Stop including vector (NFC)</title>
<updated>2023-12-04T06:32:21+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2023-12-04T06:32:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=92c2529ccde4a7eff344acd4ba22bf9d4af26b9d'/>
<id>92c2529ccde4a7eff344acd4ba22bf9d4af26b9d</id>
<content type='text'>
Identified with clangd.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Identified with clangd.
</pre>
</div>
</content>
</entry>
<entry>
<title>[llvm] Stop including llvm/ADT/DenseMap.h (NFC)</title>
<updated>2023-11-11T18:07:19+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2023-11-11T18:07:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d4360e428ffd3fffcd587e4b5de913d9ca37dd55'/>
<id>d4360e428ffd3fffcd587e4b5de913d9ca37dd55</id>
<content type='text'>
Ientified with clangd.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Ientified with clangd.
</pre>
</div>
</content>
</entry>
<entry>
<title>[Inliner] Mark inlinings stopped with inlining history as noinline</title>
<updated>2023-05-25T16:55:53+00:00</updated>
<author>
<name>Arthur Eubanks</name>
<email>aeubanks@google.com</email>
</author>
<published>2023-05-19T19:35:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=aceaea67848efa666a11f329926e8654b4826051'/>
<id>aceaea67848efa666a11f329926e8654b4826051</id>
<content type='text'>
The inline history makes sure that we don't keep inlining due to mutual devirtualization. But this gets forgotten between inliner invocations.

So mark the inlined calls as noinline so we respect previous inline history decisions.

This overlaps with D121084, but they're not redundant since we may not inline completely through a child SCC, but we still want a cost multiplier when that happens.

See discussions in D145516.

Reviewed By: jmorse

Differential Revision: https://reviews.llvm.org/D150989
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The inline history makes sure that we don't keep inlining due to mutual devirtualization. But this gets forgotten between inliner invocations.

So mark the inlined calls as noinline so we respect previous inline history decisions.

This overlaps with D121084, but they're not redundant since we may not inline completely through a child SCC, but we still want a cost multiplier when that happens.

See discussions in D145516.

Reviewed By: jmorse

Differential Revision: https://reviews.llvm.org/D150989
</pre>
</div>
</content>
</entry>
</feed>
