This is an archive of the discontinued LLVM Phabricator instance.

[MemProf] Control availability of hot/cold operator new from LTO link
ClosedPublic

Authored by tejohnson on Apr 25 2023, 4:27 PM.

Details

Summary

Adds an LTO option to indicate that whether we are linking with an
allocator that supports hot/cold operator new interfaces. If not,
at the start of the LTO backends any existing memprof hot/cold
attributes are removed from the IR, and we also remove memprof metadata
so that post-LTO inlining doesn't add any new attributes.

This is done via setting a new flag in the module summary index. It is
important to communicate via the index to the LTO backends so that
distributed ThinLTO handles this correctly, as they are invoked by
separate clang processes and the combined index is how we communicate
information from the LTO link. Specifically, for distributed ThinLTO the
LTO related processes look like:

# Thin link:
$ lld --thinlto-index-only obj1.o ... objN.o -llib ...
# ThinLTO backends:
$ clang -x ir obj1.o -fthinlto-index=obj1.o.thinlto.bc -c -O2
...
$ clang -x ir objN.o -fthinlto-index=objN.o.thinlto.bc -c -O2

It is during the thin link (lld --thinlto-index-only) that we have
visibility into linker dependences and want to be able to pass the new
option via -Wl,-supports-hot-cold-new. This will be recorded in the
summary indexes created for the distributed backend processes
(*.thinlto.bc) and queried from there, so that we don't need to know
during those individual clang backends what allocation library was
linked. Since in-process ThinLTO and regular LTO also use a combined
index, for consistency we query the flag out of the index in all LTO
backends.

Additionally, when the LTO option is disabled, exit early from the
MemProfContextDisambiguation handling performed during LTO, as this is
unnecessary.

Depends on D149117 and D149192.

Diff Detail

Event Timeline

tejohnson created this revision.Apr 25 2023, 4:27 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 25 2023, 4:27 PM
tejohnson requested review of this revision.Apr 25 2023, 4:27 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptApr 25 2023, 4:27 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript

This was refactored out of patch 3 (the applyImport stuff that I refactored into patch 4 in D149117). Previously I was controlling this behavior via the MemProfContextDisambiguation pass itself, but in refactoring I realized that it is much cleaner and more sensible to be controlling it separately via LTO. I also realized it wasn't being tested, so added some new tests here.

llvm/test/ThinLTO/X86/memprof-basic.ll
82–83

Ignore this and similar differences, need to rebase this on top of my more recent version of D149117 that removed these duplicate invocations of test RUN lines.

tejohnson updated this revision to Diff 517043.Apr 25 2023, 9:32 PM

Rebase onto latest D149117 to remove extraneous test diffs

tejohnson updated this revision to Diff 517044.Apr 25 2023, 9:39 PM

Remove extraneous call

tejohnson edited the summary of this revision. (Show Details)Apr 27 2023, 12:23 PM
tejohnson edited the summary of this revision. (Show Details)

Expand command and patch description for mechanism used by distributed ThinLTO

pcc added a subscriber: pcc.Apr 27 2023, 12:38 PM

Adds an LTO option

Usual question: does it need to be an option? Could the allocator expose a symbol such as __malloc_hot_cold that the linker could check for in the symbol table?

Adds an LTO option

Usual question: does it need to be an option? Could the allocator expose a symbol such as __malloc_hot_cold that the linker could check for in the symbol table?

I thought about doing something like that, but the disadvantage is that it requires support in the linkers (presumably at least both lld and the gold plugin), instead of being centralized in LTO itself. That being said, I do see existing lld code that currently looks for certain special __* symbols, so maybe this would be ok. I agree it would be nice to have something automatic, at least longer term. However, I think we need the internal option anyway, for testing (especially via opt for simulating regular LTO). What do you think of my adding a TODO to investigate the approach you are suggesting here?

pcc added a comment.Apr 27 2023, 1:52 PM

Adds an LTO option

Usual question: does it need to be an option? Could the allocator expose a symbol such as __malloc_hot_cold that the linker could check for in the symbol table?

I thought about doing something like that, but the disadvantage is that it requires support in the linkers (presumably at least both lld and the gold plugin), instead of being centralized in LTO itself. That being said, I do see existing lld code that currently looks for certain special __* symbols, so maybe this would be ok. I agree it would be nice to have something automatic, at least longer term. However, I think we need the internal option anyway, for testing (especially via opt for simulating regular LTO). What do you think of my adding a TODO to investigate the approach you are suggesting here?

That's fine.

tejohnson updated this revision to Diff 518721.May 2 2023, 7:28 AM

Address comment (add TODO about automatically detecting support)

snehasish accepted this revision.May 2 2023, 12:01 PM

lgtm

llvm/lib/Transforms/IPO/MemProfContextDisambiguation.cpp
3199

Thanks for adding this comment to clarify

This revision is now accepted and ready to land.May 2 2023, 12:01 PM
This revision was landed with ongoing or failed builds.May 8 2023, 8:02 AM
This revision was automatically updated to reflect the committed changes.