[llvm-bugs] [Bug 47946] New: Improve debug info accuracy for locals after inlining escaping function

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=47946

            Bug ID: 47946
           Summary: Improve debug info accuracy for locals after inlining
                    escaping function
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Transformation Utilities
          Assignee: unassignedbugs at nondot.org
          Reporter: orlando.hyams at sony.com
                CC: llvm-bugs at lists.llvm.org

Version:
clang @ 234c47ae2a8e with D85555 and D89810 applied (both currently approved).

The problem:
InstCombine's LowerDbgDeclare effectively means that we follow all the source
assignment values for any given variable throughout a function. That is no
longer true after inlining if a caller-local variable is written to by the
callee because we don't track the callee's uses of the variable in the same
way, which is undesirable. The purpose of this ticket is to document this and
to propose a solution (mentioned here [1]).

Prior to D85555 and D89810 the root problem still existed but it manifested in
a different way.

An example manifestation of the problem:
$ cat -n test.c
     1  int g;
     2  __attribute__((__always_inline__))
     3  static void use(int* p) {
     4    g = *p;
     5    *p = 0xff;
     6  }
     7  __attribute__((__noinline__))
     8  void fun(int param) {
     9    use(&param);
    10  }
    11  int main() {
    12    fun(5);
    13  }

Compiling with -O2 -g, the combination of LowerDbgDeclare and inlining cause us
to show the value 5 instead of 255 for 'param' after, and while, stepping
through inlined function 'use' in 'fun'.

Early in the pipeline, 'param' in 'fun' lives on the stack because it is
escaped by 'use'. InstCombine runs LowerDbgDeclare, inserting a
dbg.value(%stored_value) before the store to the alloca, and a
dbg.value(%alloca_addr, [DW_OP_deref]) before the 'use' call. The inliner then
pulls the body of 'use' into 'fun'. mem2reg notices that the 0xff store is
redundant and that the remaining store/load pair can be promoted, which means
that it can remove param's alloca. With D89810, we remove the
dbg.value(%alloca_addr, [DW_OP_deref]), which would've otherwise become undef.
Now the location dbg.value(%store_value) will cover the inlined scope and the
rest of the function, including after the DSE'd 0xff assignment, which is
misleading.

Proposed solution:
Teach the inliner to insert dbg.values in the same pattern as LowerDbgDeclare
[2] for uses of caller-local allocas. For the example above, we would have the
inliner insert a dbg.value(%stored_value_0xff, "param", DIExpression()) before
the inlined store *p = 0xff. After the store is deleted we'd end up with a
salvagedOrUndef dbg.value at the store site.

[1] https://reviews.llvm.org/D89810#2343831
[2] LowerDbgDeclare
https://github.com/llvm/llvm-project/blob/e2858bf633b548cbf4e31b6b10852fccde940270/llvm/lib/Transforms/Utils/Local.cpp#L1499

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20201022/18264a9b/attachment.html>