<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/llvm/lib/Analysis/LazyCallGraph.cpp, branch main</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>[llvm] Use range constructors of *Set (NFC) (#133549)</title>
<updated>2025-03-29T02:55:18+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2025-03-29T02:55:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d4427f308eb6e42790a36b56d61b482cbc9f67ba'/>
<id>d4427f308eb6e42790a36b56d61b482cbc9f67ba</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "[Coroutines][LazyCallGraph] addSplitRefRecursiveFunctions allows spurious ref edges between new functions." (#127285)</title>
<updated>2025-02-15T00:42:28+00:00</updated>
<author>
<name>Arthur Eubanks</name>
<email>aeubanks@google.com</email>
</author>
<published>2025-02-15T00:42:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=caaa288fa3658b40a35a8e327bf140921ecfaaf9'/>
<id>caaa288fa3658b40a35a8e327bf140921ecfaaf9</id>
<content type='text'>
Reverts llvm/llvm-project#116285

Breaks expensive checks build, e.g.
https://lab.llvm.org/buildbot/#/builders/16/builds/13821</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Reverts llvm/llvm-project#116285

Breaks expensive checks build, e.g.
https://lab.llvm.org/buildbot/#/builders/16/builds/13821</pre>
</div>
</content>
</entry>
<entry>
<title>[Coroutines][LazyCallGraph] addSplitRefRecursiveFunctions allows spurious ref edges between new functions. (#116285)</title>
<updated>2025-02-14T21:55:06+00:00</updated>
<author>
<name>Tyler Nowicki</name>
<email>tyler.nowicki@amd.com</email>
</author>
<published>2025-02-14T21:55:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=c662103c6ead3bbfad9bc24d7770552163dbb92b'/>
<id>c662103c6ead3bbfad9bc24d7770552163dbb92b</id>
<content type='text'>
The addSplitRefRecursiveFunctions LazyCallGraph helper should not
require a reference between every new function. Spurious ref edges
between the new functions are allowed and the new function are
considered to be a RefSCC. This change clarifies that this is the case
in the method's description and its DEBUG mode verifier.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The addSplitRefRecursiveFunctions LazyCallGraph helper should not
require a reference between every new function. Spurious ref edges
between the new functions are allowed and the new function are
considered to be a RefSCC. This change clarifies that this is the case
in the method's description and its DEBUG mode verifier.</pre>
</div>
</content>
</entry>
<entry>
<title>[llvm] Support llvm::Any across shared libraries on windows (#108051)</title>
<updated>2024-10-24T05:07:13+00:00</updated>
<author>
<name>Thomas Fransham</name>
<email>tfransham@gmail.com</email>
</author>
<published>2024-10-24T05:07:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=b8fddca7bdb354d51e340c60aafe3dff1b35a195'/>
<id>b8fddca7bdb354d51e340c60aafe3dff1b35a195</id>
<content type='text'>
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&lt;LoopNest&gt;`</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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&lt;LoopNest&gt;`</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>[CGSCC] Verify that call graph is valid after iteration (#94692)</title>
<updated>2024-06-07T17:26:09+00:00</updated>
<author>
<name>Arthur Eubanks</name>
<email>aeubanks@google.com</email>
</author>
<published>2024-06-07T17:26:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=6f2c61071c274a1b5e212e6ad4114641ec7c7fc3'/>
<id>6f2c61071c274a1b5e212e6ad4114641ec7c7fc3</id>
<content type='text'>
Only in expensive checks, to match other LazyCallGraph verification.

Is helpful for verifying LazyCallGraph updates. Many issues only surface
when we reuse the LazyCallGraph.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Only in expensive checks, to match other LazyCallGraph verification.

Is helpful for verifying LazyCallGraph updates. Many issues only surface
when we reuse the LazyCallGraph.</pre>
</div>
</content>
</entry>
<entry>
<title>[LazyCallGraph] Assert in removeDeadFunction() that NodeMap contains function</title>
<updated>2024-06-04T20:35:33+00:00</updated>
<author>
<name>Arthur Eubanks</name>
<email>aeubanks@google.com</email>
</author>
<published>2024-06-04T20:28:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=eca9caf419d420604ab372ddcab4781e999c1fe4'/>
<id>eca9caf419d420604ab372ddcab4781e999c1fe4</id>
<content type='text'>
The function should always be known to LazyCallGraph
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The function should always be known to LazyCallGraph
</pre>
</div>
</content>
</entry>
<entry>
<title>Move from llvm::makeArrayRef to ArrayRef deduction guides - llvm/ part</title>
<updated>2023-01-05T13:11:08+00:00</updated>
<author>
<name>serge-sans-paille</name>
<email>sguelton@mozilla.com</email>
</author>
<published>2023-01-04T07:28:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=38818b60c58c76ba89b990978cdfd2d7b6799260'/>
<id>38818b60c58c76ba89b990978cdfd2d7b6799260</id>
<content type='text'>
Use deduction guides instead of helper functions.

The only non-automatic changes have been:

1. ArrayRef(some_uint8_pointer, 0) needs to be changed into ArrayRef(some_uint8_pointer, (size_t)0) to avoid an ambiguous call with ArrayRef((uint8_t*), (uint8_t*))
2. CVSymbol sym(makeArrayRef(symStorage)); needed to be rewritten as CVSymbol sym{ArrayRef(symStorage)}; otherwise the compiler is confused and thinks we have a (bad) function prototype. There was a few similar situation across the codebase.
3. ADL doesn't seem to work the same for deduction-guides and functions, so at some point the llvm namespace must be explicitly stated.
4. The "reference mode" of makeArrayRef(ArrayRef&lt;T&gt; &amp;) that acts as no-op is not supported (a constructor cannot achieve that).

Per reviewers' comment, some useless makeArrayRef have been removed in the process.

This is a follow-up to https://reviews.llvm.org/D140896 that introduced
the deduction guides.

Differential Revision: https://reviews.llvm.org/D140955
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Use deduction guides instead of helper functions.

The only non-automatic changes have been:

1. ArrayRef(some_uint8_pointer, 0) needs to be changed into ArrayRef(some_uint8_pointer, (size_t)0) to avoid an ambiguous call with ArrayRef((uint8_t*), (uint8_t*))
2. CVSymbol sym(makeArrayRef(symStorage)); needed to be rewritten as CVSymbol sym{ArrayRef(symStorage)}; otherwise the compiler is confused and thinks we have a (bad) function prototype. There was a few similar situation across the codebase.
3. ADL doesn't seem to work the same for deduction-guides and functions, so at some point the llvm namespace must be explicitly stated.
4. The "reference mode" of makeArrayRef(ArrayRef&lt;T&gt; &amp;) that acts as no-op is not supported (a constructor cannot achieve that).

Per reviewers' comment, some useless makeArrayRef have been removed in the process.

This is a follow-up to https://reviews.llvm.org/D140896 that introduced
the deduction guides.

Differential Revision: https://reviews.llvm.org/D140955
</pre>
</div>
</content>
</entry>
<entry>
<title>[LazyCallGraph] Handle spurious ref edges when deleting a dead function</title>
<updated>2022-09-22T22:01:15+00:00</updated>
<author>
<name>Arthur Eubanks</name>
<email>aeubanks@google.com</email>
</author>
<published>2022-09-14T23:01:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=a8f1da128d86d86a3efc1e96e46ace725bf4f3cb'/>
<id>a8f1da128d86d86a3efc1e96e46ace725bf4f3cb</id>
<content type='text'>
Spurious ref edges are ref edges that still exist in the call graph even
though the corresponding IR reference no longer exists. This can cause
issues when deleting a dead function which has a spurious ref edge
pointed at it because currently we expect the dead function's RefSCC to
be trivial.

In the case that the dead function's RefSCC is not trivial, remove all
ref edges from other nodes in the RefSCC to it.

Removing a ref edge can result in splitting RefSCCs. There's actually no
reason to revisit those RefSCCs because currently we only run passes on
SCCs, and we've already added all SCCs in the RefSCC to the worklist.
(as opposed to removing the ref edge in
updateCGAndAnalysisManagerForPass() which can modify the call graph of
SCCs we have not visited yet). We also don't expect that RefSCC
refinement will allow us to glean any more information for optimization
use. Also, doing so would drastically increase the complexity of
LazyCallGraph::removeDeadFunction(), requiring us to return a list of
invalidated RefSCCs and new RefSCCs to add to the worklist.

Fixes #56503

Reviewed By: asbirlea

Differential Revision: https://reviews.llvm.org/D133907
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Spurious ref edges are ref edges that still exist in the call graph even
though the corresponding IR reference no longer exists. This can cause
issues when deleting a dead function which has a spurious ref edge
pointed at it because currently we expect the dead function's RefSCC to
be trivial.

In the case that the dead function's RefSCC is not trivial, remove all
ref edges from other nodes in the RefSCC to it.

Removing a ref edge can result in splitting RefSCCs. There's actually no
reason to revisit those RefSCCs because currently we only run passes on
SCCs, and we've already added all SCCs in the RefSCC to the worklist.
(as opposed to removing the ref edge in
updateCGAndAnalysisManagerForPass() which can modify the call graph of
SCCs we have not visited yet). We also don't expect that RefSCC
refinement will allow us to glean any more information for optimization
use. Also, doing so would drastically increase the complexity of
LazyCallGraph::removeDeadFunction(), requiring us to return a list of
invalidated RefSCCs and new RefSCCs to add to the worklist.

Fixes #56503

Reviewed By: asbirlea

Differential Revision: https://reviews.llvm.org/D133907
</pre>
</div>
</content>
</entry>
<entry>
<title>[LazyCallGraph] Reformat the code in accordance with the code style. NFC</title>
<updated>2022-08-30T08:06:42+00:00</updated>
<author>
<name>Pavel Samolysov</name>
<email>samolisov@gmail.com</email>
</author>
<published>2022-08-27T12:22:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=88581db62f55db4094aba122685c693609d382b4'/>
<id>88581db62f55db4094aba122685c693609d382b4</id>
<content type='text'>
Also, some local variables were renamed in accordance with the code
style as well as `std::tie` occurrences and `.first`/`.second` member
uses were replaced with structure bindings.

Differential Revision: https://reviews.llvm.org/D132806
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Also, some local variables were renamed in accordance with the code
style as well as `std::tie` occurrences and `.first`/`.second` member
uses were replaced with structure bindings.

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