[all-commits] [llvm/llvm-project] 839fd9: [DebugInfo][AT] Treat escaping calls as untagged s...

[Shivam Kunwar via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 839fd9177e99cd2e1eafe7109cc96efa860e2537
      https://github.com/llvm/llvm-project/commit/839fd9177e99cd2e1eafe7109cc96efa860e2537
  Author: Shivam Kunwar <75530356+phyBrackets at users.noreply.github.com>
  Date:   2026-03-12 (Thu, 12 Mar 2026)

  Changed paths:
    M llvm/docs/AssignmentTracking.md
    M llvm/lib/CodeGen/AssignmentTrackingAnalysis.cpp
    A llvm/test/DebugInfo/assignment-tracking/AArch64/escaping-call-tag-offset.ll
    M llvm/test/DebugInfo/assignment-tracking/X86/diamond-3.ll
    A llvm/test/DebugInfo/assignment-tracking/X86/escaping-call.ll
    M llvm/test/DebugInfo/assignment-tracking/X86/loop-hoist.ll
    M llvm/test/DebugInfo/assignment-tracking/X86/mem-loc-frag-fill.ll
    M llvm/test/DebugInfo/assignment-tracking/X86/negative-offset.ll

  Log Message:
  -----------
  [DebugInfo][AT] Treat escaping calls as untagged stores in assignment tracking (#183979)

When a pointer to a tracked alloca is passed to a call that may write
through it (e.g. foo(&x)), the callee can modify the variable's stack
home. The assignment tracking analysis didn't account for this, which
could cause the debugger to show stale values after such calls.

Consider:

```
  int x = 1;
  foo(&x);    // might set x to 99
  x = 2;      // store deleted by DSE
```

Without this patch, the analysis still thinks the stack home holds
assignment `!id1` after the call. When it later sees the `dbg_assign`
for the deleted store, the mismatch causes it to fall back to the old
debug value (1) , which is wrong.

Fix this by detecting calls where a tracked `alloca` escapes as an
argument and treating them the same way we already treat untagged
stores, set both `StackHome` and `Debug` to NoneOrPhi (unknown
assignment) and keep `LocKind` as Mem (the stack slot is still the right
place to look). This causes a `DBG_VALUE` with `DW_OP_deref` to be
emitted after
the call, telling the debugger to read whatever is actually in memory.

Pointer arguments with readonly, readnone, or byval attributes are
skipped since the callee either cannot modify the original memory or
receives a copy. Intrinsics are also skipped since their memory effects
are already modeled individually (e.g. memset/memcpy as stores, lifetime
markers as no-ops).

---------

Co-authored-by: Shivam Kunwar <phyBrackets at users.noreply.github.com>



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