aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/MachineVerifier.cpp
diff options
context:
space:
mode:
authorTeresa Johnson <tejohnson@google.com>2025-01-29 18:22:14 -0800
committerGitHub <noreply@github.com>2025-01-29 18:22:14 -0800
commit6c3bf341144dbaf6dc3f91301b52ffacfea55726 (patch)
treeb9a619760a222e404797def731ffec1db0be4f8c /llvm/lib/CodeGen/MachineVerifier.cpp
parenta3a3e6997bd7bd82cce6737c1315019704a846ed (diff)
downloadllvm-6c3bf341144dbaf6dc3f91301b52ffacfea55726.zip
llvm-6c3bf341144dbaf6dc3f91301b52ffacfea55726.tar.gz
llvm-6c3bf341144dbaf6dc3f91301b52ffacfea55726.tar.bz2
[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).
Diffstat (limited to 'llvm/lib/CodeGen/MachineVerifier.cpp')
0 files changed, 0 insertions, 0 deletions