[all-commits] [llvm/llvm-project] 6c3bf3: [MemProf] Fix summary identification for imported ...

[Teresa Johnson via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 6c3bf341144dbaf6dc3f91301b52ffacfea55726
      https://github.com/llvm/llvm-project/commit/6c3bf341144dbaf6dc3f91301b52ffacfea55726
  Author: Teresa Johnson <tejohnson at google.com>
  Date:   2025-01-29 (Wed, 29 Jan 2025)

  Changed paths:
    M llvm/lib/AsmParser/LLParser.cpp
    M llvm/lib/Transforms/IPO/MemProfContextDisambiguation.cpp
    A llvm/test/ThinLTO/X86/memprof_imported_internal.ll
    A llvm/test/ThinLTO/X86/memprof_imported_internal2.ll

  Log Message:
  -----------
  [MemProf] Fix summary identification for imported locals (#124659)

When we apply cloning decisions in the ThinLTO backend, we need to find
the corresponding summary for each function in the IR, and in some cases
for callee functions. This is complicated when the function was a
promoted local, in which case the GUID was formed from the hash of the
original source file prepended to the function name. Those functions
can be identified by the fact that they were given a ".llvm." suffix
during promotion.

We previously didn't do this correctly for promoted locals imported from
other modules, as we only tried the current module source name. This led
to crashes, in particular when the current module also had an local
function of the same original name. In particular, we were attempting to
iterate through the wrong summary's callsites, and there were fewer than
in the actual function so we accessed data off the end (in a release
build with assertion checking off - with assertion checking on we double
check the stack ids and that would have failed). Even if we hadn't
crashed or hit an assert, we could have applied the wrong cloning
decisions, leading to unsats at link time.

Luckily, function importing attaches thinlto_src_file metadata
containing the original source file name to all imported functions. It
normally doesn't do this by default, however, it always does if MemProf
context disambiguation is enabled. Therefore, we can just look to see if
the function contains this metadata and if so use it to recreate the
original GUID.

A similar issue can occur when looking for the ValueInfo / GUID of
a direct tail call to see if we synthesized a callsite record for a
missing tail call frame. In that case, the callee function may be a
declaration, if we imported its caller but not the callee function
definition. Because imported declarations don't get the thinlto_src_file
metadata, we instead look at its caller (which works because this
happens very early in the backend before any inlining).



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications