<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/llvm/lib/LTO/LTO.cpp, branch users/fmayer/spr/main.wip-smartpointers</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>[ThinLTO] Add index flag for internalization/promotion status (#164530)</title>
<updated>2025-10-22T14:30:43+00:00</updated>
<author>
<name>Teresa Johnson</name>
<email>tejohnson@google.com</email>
</author>
<published>2025-10-22T14:30:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=eb74d8e03cef0bb29bccf221f5ea565e47d7ab26'/>
<id>eb74d8e03cef0bb29bccf221f5ea565e47d7ab26</id>
<content type='text'>
Add an index-wide flag indicating whether index-based internalization
and promotion have completed. This will be used in a follow on change.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add an index-wide flag indicating whether index-based internalization
and promotion have completed. This will be used in a follow on change.</pre>
</div>
</content>
</entry>
<entry>
<title>[ThinLTO] Make SummaryList private (NFC) (#164355)</title>
<updated>2025-10-21T13:53:40+00:00</updated>
<author>
<name>Teresa Johnson</name>
<email>tejohnson@google.com</email>
</author>
<published>2025-10-21T13:53:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=683e2bf059a6e5e0bb9dc2628218b53dc2d1b490'/>
<id>683e2bf059a6e5e0bb9dc2628218b53dc2d1b490</id>
<content type='text'>
In preparation for a follow on change that will require checking every
time a new summary is added to the SummaryList for a GUID, make the
SummaryList private and require all accesses to go through one of two
new interfaces. Most changes are to access the list via the read only
getSummaryList() method, and the few that add new summaries (e.g. while
building the combined summary) use the new addSummary() method.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In preparation for a follow on change that will require checking every
time a new summary is added to the SummaryList for a GUID, make the
SummaryList private and require all accesses to go through one of two
new interfaces. Most changes are to access the list via the read only
getSummaryList() method, and the few that add new summaries (e.g. while
building the combined summary) use the new addSummary() method.</pre>
</div>
</content>
</entry>
<entry>
<title>[MemProf] Convert removal of memprof attrs and metadata to a pass (#163841)</title>
<updated>2025-10-16T19:25:51+00:00</updated>
<author>
<name>Teresa Johnson</name>
<email>tejohnson@google.com</email>
</author>
<published>2025-10-16T19:25:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=2a7e7e2ac40a8bad2629a7790538e4ff608501ab'/>
<id>2a7e7e2ac40a8bad2629a7790538e4ff608501ab</id>
<content type='text'>
In preparation for a follow on fix that removes these attributes and
metadata in non-LTO pipelines, convert updateMemProfAttributes to a new
MemProfRemoveInfo pass that executes at the start of the LTO backend
pass pipelines when we don't have an index indicating that we linked
with a library support hot cold operator new.

This is largely NFC from an end user perspective but changes where the
removal can be observed, hence the test updates.

A follow on change will use the new pass for non-LTO pipelines (for
cases when the bitcode is initially matched with memprof data but we
decide to complete the compile without LTO).</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In preparation for a follow on fix that removes these attributes and
metadata in non-LTO pipelines, convert updateMemProfAttributes to a new
MemProfRemoveInfo pass that executes at the start of the LTO backend
pass pipelines when we don't have an index indicating that we linked
with a library support hot cold operator new.

This is largely NFC from an end user perspective but changes where the
removal can be observed, hence the test updates.

A follow on change will use the new pass for non-LTO pipelines (for
cases when the bitcode is initially matched with memprof data but we
decide to complete the compile without LTO).</pre>
</div>
</content>
</entry>
<entry>
<title>Cleanup the LLVM exported symbols namespace (#161240)</title>
<updated>2025-10-01T22:32:07+00:00</updated>
<author>
<name>Nicolai Hähnle</name>
<email>nicolai.haehnle@amd.com</email>
</author>
<published>2025-10-01T22:32:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=11a4b2d950baa4ddb31505b71a1736fa1f3242b6'/>
<id>11a4b2d950baa4ddb31505b71a1736fa1f3242b6</id>
<content type='text'>
There's a pattern throughout LLVM of cl::opts being exported. That in
itself is probably a bit unfortunate, but what's especially bad about it
is that a lot of those symbols are in the global namespace. Move them
into the llvm namespace.

While doing this, I noticed some other variables in the global namespace
and moved them as well.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There's a pattern throughout LLVM of cl::opts being exported. That in
itself is probably a bit unfortunate, but what's especially bad about it
is that a lot of those symbols are in the global namespace. Move them
into the llvm namespace.

While doing this, I noticed some other variables in the global namespace
and moved them as well.</pre>
</div>
</content>
</entry>
<entry>
<title>[Remarks] Restructure bitstream remarks to be fully standalone (#156715)</title>
<updated>2025-09-22T15:41:39+00:00</updated>
<author>
<name>Tobias Stadler</name>
<email>mail@stadler-tobias.de</email>
</author>
<published>2025-09-22T15:41:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=dfbd76bda01e804a66c3750193f5e766e4e4cf62'/>
<id>dfbd76bda01e804a66c3750193f5e766e4e4cf62</id>
<content type='text'>
Currently there are two serialization modes for bitstream Remarks:
standalone and separate. The separate mode splits remark metadata (e.g.
the string table) from actual remark data. The metadata is written into
the object file by the AsmPrinter, while the remark data is stored in a
separate remarks file. This means we can't use bitstream remarks with
tools like opt that don't generate an object file. Also, it is confusing
to post-process bitstream remarks files, because only the standalone
files can be read by llvm-remarkutil. We always need to use dsymutil
to convert the separate files to standalone files, which only works for
MachO. It is not possible for clang/opt to directly emit bitstream
remark files in standalone mode, because the string table can only be
serialized after all remarks were emitted.

Therefore, this change completely removes the separate serialization
mode. Instead, the remark string table is now always written to the end
of the remarks file. This requires us to tell the serializer when to
finalize remark serialization. This automatically happens when the
serializer goes out of scope. However, often the remark file goes out of
scope before the serializer is destroyed. To diagnose this, I have added
an assert to alert users that they need to explicitly call
finalizeLLVMOptimizationRemarks.

This change paves the way for further improvements to the remark
infrastructure, including more tooling (e.g. #159784), size optimizations
for bitstream remarks, and more.

Pull Request: https://github.com/llvm/llvm-project/pull/156715
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently there are two serialization modes for bitstream Remarks:
standalone and separate. The separate mode splits remark metadata (e.g.
the string table) from actual remark data. The metadata is written into
the object file by the AsmPrinter, while the remark data is stored in a
separate remarks file. This means we can't use bitstream remarks with
tools like opt that don't generate an object file. Also, it is confusing
to post-process bitstream remarks files, because only the standalone
files can be read by llvm-remarkutil. We always need to use dsymutil
to convert the separate files to standalone files, which only works for
MachO. It is not possible for clang/opt to directly emit bitstream
remark files in standalone mode, because the string table can only be
serialized after all remarks were emitted.

Therefore, this change completely removes the separate serialization
mode. Instead, the remark string table is now always written to the end
of the remarks file. This requires us to tell the serializer when to
finalize remark serialization. This automatically happens when the
serializer goes out of scope. However, often the remark file goes out of
scope before the serializer is destroyed. To diagnose this, I have added
an assert to alert users that they need to explicitly call
finalizeLLVMOptimizationRemarks.

This change paves the way for further improvements to the remark
infrastructure, including more tooling (e.g. #159784), size optimizations
for bitstream remarks, and more.

Pull Request: https://github.com/llvm/llvm-project/pull/156715
</pre>
</div>
</content>
</entry>
<entry>
<title>[LLD][COFF] Add more `--time-trace` tags for ThinLTO linking (#156471)</title>
<updated>2025-09-05T19:28:19+00:00</updated>
<author>
<name>Alexandre Ganea</name>
<email>aganea@havenstudios.com</email>
</author>
<published>2025-09-05T19:28:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=5cda2424c8f9a0ecac2cc9f6c7f41883a16bea12'/>
<id>5cda2424c8f9a0ecac2cc9f6c7f41883a16bea12</id>
<content type='text'>
In order to better see what's going on during ThinLTO linking, this PR
adds more profile tags when using `--time-trace` on a `lld-link.exe`
invocation.

After PR, linking `clang.exe`:

&lt;img width="3839" height="2026" alt="Capture d’écran 2025-09-02 082021"
src="https://github.com/user-attachments/assets/bf0c85ba-2f85-4bbf-a5c1-800039b56910"
/&gt;

Linking a custom (Unreal Engine game) binary gives a completly
different picture, probably because of using Unity files, and the sheer
amount of input files (here, providing over 60 GB of .OBJs/.LIBs).

&lt;img width="1940" height="1008" alt="Capture d’écran 2025-09-02 102048"
src="https://github.com/user-attachments/assets/60b28630-7995-45ce-9e8c-13f3cb5312e0"
/&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In order to better see what's going on during ThinLTO linking, this PR
adds more profile tags when using `--time-trace` on a `lld-link.exe`
invocation.

After PR, linking `clang.exe`:

&lt;img width="3839" height="2026" alt="Capture d’écran 2025-09-02 082021"
src="https://github.com/user-attachments/assets/bf0c85ba-2f85-4bbf-a5c1-800039b56910"
/&gt;

Linking a custom (Unreal Engine game) binary gives a completly
different picture, probably because of using Unity files, and the sheer
amount of input files (here, providing over 60 GB of .OBJs/.LIBs).

&lt;img width="1940" height="1008" alt="Capture d’écran 2025-09-02 102048"
src="https://github.com/user-attachments/assets/60b28630-7995-45ce-9e8c-13f3cb5312e0"
/&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>Reapply "RuntimeLibcalls: Generate table of libcall name lengths (#153… (#153864)</title>
<updated>2025-08-16T00:53:50+00:00</updated>
<author>
<name>Matt Arsenault</name>
<email>Matthew.Arsenault@amd.com</email>
</author>
<published>2025-08-16T00:28:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=3e5d8a1439afb784dee1a12a878fa0a533a6d4c6'/>
<id>3e5d8a1439afb784dee1a12a878fa0a533a6d4c6</id>
<content type='text'>
This reverts commit 334e9bf2dd01fbbfe785624c0de477b725cde6f2.

Check if llvm-nm exists before building the benchmark.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 334e9bf2dd01fbbfe785624c0de477b725cde6f2.

Check if llvm-nm exists before building the benchmark.
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "RuntimeLibcalls: Generate table of libcall name lengths (#153… (#153864)</title>
<updated>2025-08-15T20:32:27+00:00</updated>
<author>
<name>gulfemsavrun</name>
<email>gulfem@google.com</email>
</author>
<published>2025-08-15T20:32:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=334e9bf2dd01fbbfe785624c0de477b725cde6f2'/>
<id>334e9bf2dd01fbbfe785624c0de477b725cde6f2</id>
<content type='text'>
…210)"

This reverts commit 9a14b1d254a43dc0d4445c3ffa3d393bca007ba3.

Revert "RuntimeLibcalls: Return StringRef for libcall names (#153209)"

This reverts commit cb1228fbd535b8f9fe78505a15292b0ba23b17de.

Revert "TableGen: Emit statically generated hash table for runtime
libcalls (#150192)"

This reverts commit 769a9058c8d04fc920994f6a5bbb03c8a4fbcd05.

Reverted three changes because of a CMake error while building llvm-nm
as reported in the following PR:
https://github.com/llvm/llvm-project/pull/150192#issuecomment-3192223073</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
…210)"

This reverts commit 9a14b1d254a43dc0d4445c3ffa3d393bca007ba3.

Revert "RuntimeLibcalls: Return StringRef for libcall names (#153209)"

This reverts commit cb1228fbd535b8f9fe78505a15292b0ba23b17de.

Revert "TableGen: Emit statically generated hash table for runtime
libcalls (#150192)"

This reverts commit 769a9058c8d04fc920994f6a5bbb03c8a4fbcd05.

Reverted three changes because of a CMake error while building llvm-nm
as reported in the following PR:
https://github.com/llvm/llvm-project/pull/150192#issuecomment-3192223073</pre>
</div>
</content>
</entry>
<entry>
<title>RuntimeLibcalls: Return StringRef for libcall names (#153209)</title>
<updated>2025-08-15T00:55:39+00:00</updated>
<author>
<name>Matt Arsenault</name>
<email>Matthew.Arsenault@amd.com</email>
</author>
<published>2025-08-15T00:55:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=cb1228fbd535b8f9fe78505a15292b0ba23b17de'/>
<id>cb1228fbd535b8f9fe78505a15292b0ba23b17de</id>
<content type='text'>
Does not yet fully propagate this down into the TargetLowering
uses, many of which are relying on null checks on the returned
value.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Does not yet fully propagate this down into the TargetLowering
uses, many of which are relying on null checks on the returned
value.</pre>
</div>
</content>
</entry>
<entry>
<title>LTO: Fix bug, Res was meant to be InputRes.</title>
<updated>2025-07-30T21:30:00+00:00</updated>
<author>
<name>Peter Collingbourne</name>
<email>peter@pcc.me.uk</email>
</author>
<published>2025-07-30T21:29:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=6f2029dc4a293c3aca3b6efd6cc9e07723eb2368'/>
<id>6f2029dc4a293c3aca3b6efd6cc9e07723eb2368</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
</feed>
